-
Wow, that’s a lot of bloat, and a great demonstration of why I don’t use Gnome (or KDE).
I’m much happier with StumpWM, which just does its job and doesn’t try to integrate with everything.
-
Unfortunately, if you want Wayland — and I do, as it really has made all my vsync/stuttering/tearing issues go away; Fedora is now as smooth as my mac/windows — your choices are limited. Sway is starting to look good but otherwise there’s not much at the minimal end of the spectrum.
If I have to choose between GNOME and KDE, I pick GNOME for the same reasons the author of this piece does. I was hoping the tips would come down to more than “uninstall tracker, evolution daemons et al. and hope for the best”. I’ve done that before on Fedora and ended up wrangling package dependancies in yum. I really wish GNOME/Fedora would take this sort of article to heart and offer a “minimal GNOME” option which is effectively just gnome-shell.
-
Why is Wayland so poorly implemented? Is it because few distributions have it as default or is it because it’s harder? I see many tilling wm written in 50 different languages and it seems that sway is getting slowly it’s way to a usable wm, but it seems like a slow adoption from my point of view.
-
It is a slow adoption, I’m not particularly sure why. Most (all?) of the tiling wms for X leverage Xlib or XCB, right? Perhaps it’s just needed some time for a similarly mature compositor lib to appear for Wayland (indeed, Sway is replacing their initial use of wlc with wlroots which may end up being that).
As for why Wayland in general isn’t more prevalent, I’d guess compatibility. X is just so well established that replacing it is inherently a lot of work in the “last mile”. Fedora/GNOME/Wayland works great for me with my in-kernel open AMD driver. Maybe it’s not as good for Intel iGPUs? Maybe it’s not so good on Nvidia systems? Maybe it doesn’t work at all on arm SoC things? I have no idea, but I can easily understand distros holding off on making it default.
-
Maybe it’s not so good on Nvidia systems?
Exactly, the proprietary driver does not support GBM, they’ve been pushing their own thing (EGLStreams) that compositors don’t want.
Maybe it’s not as good for Intel iGPUs? Maybe it doesn’t work at all on arm SoC things?
Everything works great with any open drivers, including VC4 for the RPi.
-
Maybe it’s not as good for Intel iGPUs?
Just a data point: I’ve got a new thinkpad recently, installed linux on it, together with gnome3. Only yesterday I’ve discovered it was running on wayland the whole time, with no apparent problems what-so-ever. And that includes working with a dock with two further displays attached, and steam games. Even the touch panel on the screen works without any further config.
-
-
-
Unfortunately, if you want Wayland — and I do, as it really has made all my vsync/stuttering/tearing issues go away; Fedora is now as smooth as my mac/windows
And effortless support for multiple displays with different DPIs, plus better isolation of applications. I completely agree, when I switched to Wayland on Fedora 25 or 26, it was the first time I felt in a long time that the Linux desktop is on par again with macOS and Windows (minus some gnome-shell bugs that seem to have been mostly fixed now).
At some point, I might switch to Sway. But with Sway 0.15, X.org applications are still scaled up and blurry on a HiDPI screen (whereas they work fine in GNOME). I’ll give it another go once Sway 1.0 is out.
-
-
-
Sure, there is some, but who said you can’t reimplement that stuff?
-
libwayland, the reference implementation of client and server libraries, usesepoll. We have an epoll implementation on top of kqueue. - Most compositors use
libinputto read from input devices, andlibinput:- reads from
evdevdevices (vialibevdevbut that’s a really thin lib). We have evdev support in many drivers, including Synaptics (with TrackPoint support). - uses
libudevfor device lookup and hotplug. We have a partial libudev implementation on top of devd.
- reads from
- For GPU acceleration, compositors need a modern DRM/KMS/GBM stack with PRIME and whatnot. We have that.
- Compositors also need some way of managing a virtual terminal (vt), this is the fun part (not).
- direct vt manipulation / setuid wrapper (
weston-launch) is pretty trivial to modify to support FreeBSD, that’s how Weston and Sway work right now - I’m building a generic
weston-launchclone: loginw - ConsoleKit2 should work?? I think we might get KDE Plasma’s
kwin_waylandto work on this?? - there were some projects aimed at reimplementing
logindfor BSD, but they didn’t go anywhere…
- direct vt manipulation / setuid wrapper (
-
For GPU acceleration, compositors need a modern DRM/KMS/GBM stack with PRIME and whatnot. We have that.
Do NVidia’s drivers use the same stack, or are they incompatible with the Wayland port? I’d give Wayland a try, but it seems hard to find a starting point… I’m running CURRENT with custom Poudriere-built packages, so patches or non-standard options aren’t a problem, I just can’t find any info on how to start.
-
No, proprietary nvidia drivers are not compatible. Nvidia still does not want to support GBM, so even on Linux, support is limited (you can only use compositors that implemented EGLStreams, like… sway 0.x I think?) Plus, I’m not sure about the mode setting situation (nvidia started using actual proper KMS on Linux recently I think?? But did they do it on FreeBSD?)
It should be easy to import Nouveau to drm-next though, someone just has to do it :)
Also, you can get it to work without hardware acceleration (there is an scfb patch for Weston), but I think software rendering is unacceptable.
-
-
-
-
-
I tried to give Wayland a try twice, on both my media PC and a new Laptop. It’s still really not there yet. I use i3 on X11 and Sway is really buggy, lacks a lot of backwards compatibility stubs (notification tray icons are a big one) and just doesn’t quite match i3 yet. Weston, the reference window manager, had a lot of similar problems when using it with my media PC.
I want to move on to Wayland, and I might give that other i3 drop-in for Wayland a try in the future, but right now it’s still not there yet.
-
-
-
[Comment removed by author]
-
-
If you look over his other blog posts he mentions forcing his team to pull 7-day weeks with 12-hour days FOR EIGHT MONTHS.
I looked briefly but didn’t find that. Can you point me where you saw that?
In this article, the author mentions that Rick was working like that. That’s the only 12/7 reference I’ve found, though:
Rick was churning out code faster than ever. He was working seven-day weeks, twelve hours a day.
-
Can you point me where you saw that?
It took eight months of seven-day weeks and twelve-hour days to complete our last legacy system overhaul.
-
-
-
-
I’m author of that gist (just noticed I have some comments there I need to reply to), still running the setup, now with FreeBSD 12-CURRENT. Tl;dr it generally works, still no wi-fi support. X works fine (running with drm-next-4.7 patches to get external thunderbolt display to work; vanilla kernel works fine with built-in and DVI display, gets confused by Thunderbolt display only). Gave up on pkg because I want to control my build flags, I’m using portmaster now and thinking about setting up poudriere on a bigger server. Feel free to ask if you have any particular questions.
-
Broadcom wifi support for *BSD is limited to older chipsets, I’m afraid.
DragonflyBSD originated but has now removed bwi(4), the driver for powerbook G4 era wifi chips. FreeBSD has kept bwi(4).
FreeBSD developed bwn(4) for newer chips but it does not seem to support the very latest chips either. Perhaps that will change some day. This driver used to “not work (don’t bother porting it to OpenBSD)” last I asked, but Adrian has come up with some fixes for it since.
OpenBSD still has bwi(4) but no equivalent for bwn(4).
Your best bet is probably to use a USB dongle supported by run(4) (Ralink/Mediatek chips). There’s also urtwn(4) but the hardware tends to overheat and the quality of the driver is worse.
-
-
I thought this was a known HashiCorp thing - we’ve been using it for a while now to manage a complex multi-account AWS infrastructure, and it’s worked really well.
I’ve run into some limitations, e.g. not being able to interpolate values loaded in files, though I understand the ‘why not’. Or missing features like multi-AZ elasticache redis.
It also feels a bit dangerous since you could do something REALLY bad like wipe out your RDS instances. We always run a
plan(in our CI, even), but I do worry that somebody may miss a+/-where they expect a~(destroy/create vs modify) in the plan. We adjusted our IAM permissions to prevent deletes from most accounts to help mitigate that risk.It’s really nice to be able to manage our infrastructure as code - we keep in a git repository and have a workflow around it that way.
-
-
These are different use cases: Ansible is used to configure an installed OS; Terraform gets you from cloud API to an installed OS that Ansible (or Chef, or Puppet, or CFEngine, or a bunch of shell scripts) can manage: AWS instance, storage volumes, security groups, networking setup, DNS, and so on (I use AWS cloud as an example, because this is what I work with; Terraform supports multiple cloud providers, and to some extent non-cloud infrastructure too).
I’m not sure what open source tool could I compare Terraform to; within the AWS ecosystem, the closest thing is CloudFormation.
Edit: here’s a good overview of how Terraform is useful (half year old now, so some of the details might be out of date): https://charity.wtf/2016/02/23/two-weeks-with-terraform/
-
-
Nope, I’m fairly new to devopsing, sorry. Terraform is the only tool of this nature I’ve used.
-
-
-
In Alan Jude’s talk about advanced tricks with ZFS that I cannot remember the exact name for right now, he uses ZFS in order to treat his SVN checkout of the FreeBSD source more like git.
-
This sounds interesting, I’d really appreciate if somebody found a link to this talk (I’m trying to find it as well, will post if I succeed)
Edit: maybe it’s this (slide 19)? http://allanjude.com/talks/vBSDCon2015_-_Interesting_ZFS.pdf
-
It’s this talk:
https://www.youtube.com/watch?v=qXOZmDoy2Co
And the section I’m thinking of starts here:
-
-
-
That defer thing is really weird, and quite counterintuitive. Any rationale? Some sort of symmetry with go?
-
I would have thought of it as plenty intuitive, to be honest, but maybe that’s just my background speaking. As with most function calls, arguments are evaluated before the call happens; in this case, the call gets deferred, but it still seems to make sense that args are evaluated immediately in order to defer the call. (I’d expect
defer x(1 + 1)to evaluate1 + 1 = 2immediately, for instance.)-
-
The “finally” part is the deferred function’s body. One of the idioms with defer is to use argument to capture values rather than closing over names if you need to use
deferon e.g. theforvariable:for _, thing := range stuff { defer func(theThing Thing) { theThing.FinishIt() }(thing) thing.ProcessIt() }Whatever are the arguments for deferred function, they exist when you invoke
defer, and they may not be reachable anymore (and might have been already GCed) by the time deferred function runs. And if you need to evaluate the arguments by the time deferred function runs, you can just wrap it in another function and close over the values you need (should work, unless you’ll be using a loop variable - you’ll probably get the last value only, because it will be evaluated after the loop has finished):defer func() { closeMyNetworkConnection(networkConn, determineHowConnShouldBeClosed()) }()
-
-
-
https://common-lisp.net/project/ecl/ comes to mind, it is (or was – I was working with it 10 years ago or so) built entirely around Lisp → C transpilation and
.soloading. Because it was transpiling code to C, it was great for writing CL interfaces to C libraries without complicated FFI layers.