I didn’t claim they didn’t want access to military grade weaponry of the time, I said that at the time military grade weaponry was nearly useless without a lot of people. Yes you could have artillery, good luck trying to unilaterally do anything with that without a crew and guard (artillery were very vulnerable without a force backing them up). Good luck with the muzzle loaders when you need to reload without other people to cover

The concept of a lone actor being able to inflict mass casualty just wasn’t in the equation back then.

To the extent that we should honor their work (as opposed to it being subject for tailoring to our times) could be debated, but for sake of argument I’ll go with extrapolating their intent to the modern era.

For freedom of the press, they wanted the people to be able to communicate. It being even easier doesn’t seem to run counter to their goals, nor does it seem to complicate matters in their view.

For the religion, they did have among their ranks self-proclaimed “heretics”, so no, it wasn’t strictly about Judeo-Christian religions even from the onset.

For the right to bear arms, this one hits differently. What was their goal? It says quite plainly that states should be able to field well regulated militias, and so to do that, they need a good chunk of citizens with weapons ready to go. Those pea shooters were nigh useless except for hunting and as part of a larger force. The idea of a whole town of people self-organizing a militia might have been consistent with their goals, but the concept of a single actor able to pop off dozens of accurate lethal shots at a distance in a couple of minutes is a very distinct consideration that is wholly different than those goals and wasn’t in the equation at all.

As an American, I largely agree, but had a story that’s related.

We had someone in town for work from another country. He asks us if we carry our guns with us or keep them in our cars, because he really wanted to take a look and maybe go out shooting since his home country would never let him anywhere near a gun and that was like the one top “American” thing he wanted to try while he was here. None of us in the group actually had guns on us, in our car, or at home. This sincerely seemed to baffle him. We gave him an explanation much like yours, that the prevalence of guns might be a bit exagerated in the media, but guns rarely make an appearance, and when they do we generally also get pretty nervous because it’s so unusual.

Well this discussion was just coming up on lunch and so we go to drive him to somewhere to eat and we get outside and he asks what all those noises were. “Oh, that’s gunfire from the shooting range across the road, we kind of forgot about it and tune it out because we always hear it on days with nice weather”.

Firearms could be devastating when you had a whole bunch of people to keep up a sustained fighting despite most of the people at a given time being busy reloading (and the firearms pretty much ditched if the opponent closed on you anyway). Also the range and accuracy were crap, which was still dangerous enough when you had a volley of a bunch at once fired vaguely toward a bunch of opponents.

In terms of being afraid of what a single person could in isolation do to people, the worst they would have ever faced were blades.

The thing is that the shell provides so little innate functionality and delegates anything more to an ecosystem of random quality, and then subjects those authors to a pretty capricious interface that breaks random extensions every six months generally driving a lot of the authors to throw up their hands and give up.

So the native functionality is solid, though even lower features than Microsoft windows window management, and then have to apply dodgy extensions to get features that other solutions just have as a matter of course.

If I didn’t know any better, I would have assumed that gnome shell was some small demonstrator project to serve as a reference implementation (e.g Weston) rather than intended for serious use. I came over from gnome 2 thinking things went pretty far backwards, but the extensions are going to be stop gaps while they build back up to a balance desktop. But they never seemed to do that.

Ultimately, I landed on Plasma and that’s been pretty good. Have some embedded/kiosk stuff using sway thanks to the very nice scriptable facilities there, but still sticking with kwin as a daily driver for now.

Hup is frequently just “hey, reread your configuration files and keep going”

Heh, recently I was looking up things about terminal graphics and came upon: https://github.com/microsoft/terminal/issues/8389

And DHowett’s reply was pretty dismissive. Guess that was the tip of the iceberg.

But this anecdote is a good ‘corp’ versus ‘open source’ anecdote. There’s simply no way a business with project management would even think about optimizing performance of a terminal emulator that seems to vaguely work according to the marketing requirements. What a waste of time, right? My experience with a software development organization is 99% of management work is to rationalize away doing anything.

Meanwhile, open source someone says “screw it, this is crap, I can fix it”.

I don’t know, I mean I’ve seen a fair amount of IDE capability out of VSCode after some invested effort to try to get it there, but at it’s best I haven’t seen it as comprehensive as what I’ve seen in a Jetbrains IDE. That said, in my use case the IDE capabilities don’t apply very well anyway, so it’s moot for me and I’m happy with Kate with LSP.

I think this speaks to the potential strengths and weaknesses of open versus commercial.

It boils down to amount of resources and how they are invested.

In terms of amount of resources, open source has a rather organic pool of software developers. So if you have a use case that impacts every software developer in the world, well the open source has a lot of free labor that can produce impressive results that a commercial player would have a hard time out-spending. Conversely, if the use case is relatively more niche and the users are either not programmers or too busy using the software to do other things they couldn’t spend any on software, a commercial player can force the issue by paying some developers to work on it. Now the quality of that work may be reduced by the developers doing it for the pay without necessarily an inherent passion for the task at hand, but it can be pretty compelling and people can tend to get invested in their work even if they don’t care to start with. Incidentally it’s why at my company when they lucked into someone with actual passion for the work comes along I advocate strongly for retention, but those folks tend to be neglected and leave while some passionless sycophant gets the retention and promotion.

Then there’s how that resource is invested. Here we have professional software versus the more prolific general consumer software. In the general consumer case, the commercial interest takes the user as a given, and goes straight into how to gouge that customer relationship as hard as possible without regard for a good user experience. Stuff them with ads. Implement telemetry with rights to sell it off for marketing data. Nag them at every corner to buy some other offering at increased price. Have a confusing set of tiers and actively screw with the bottom tier. Actually making the software fit for purpose is so far below those others. With software for business, well, you still get the ‘must subscribe and confusing portfolio’, but some of the other stuff tones down. The target market is smaller, and the potential for marketing data and advertising revenue isn’t as attractive. The target market is frequently companies that take their confidentiality seriously and will readily get a lawyer to pursue issues, so the telemetry is both less valuable and a bit of a grenade waiting to go off if something screws up. So OSS tends to cover the ‘general consumer’ cases surprisingly well because the commercial interests are so much more invested in making things worse, while business to business can actually have a chance still.

Eh, I prefer KDE. It’s fairly uncluttered unless you actively mess with it and want it, whole Gnome is pretty ruthlessly “our way is the right way”.

Once upon a time they only allowed virtual desktops to be in a column. Someone decided that columns weren’t for everyone so obviously make it only be in a row. Despite ages of most implementations supporting a grid layout.

Window title search. This is fantastic for managing a lot of windows. I wish KDE could get better by using screen reader facilities to let you search window contents as well, but having the facility in show windows view at all is great.

Their window tiling is less capable even than Microsoft windows.

Any attempt to customize means extensions, and they seem to break the interfaces the extensions need constantly, and I had to face the reality that every update had me searching for a replacement extension because they broke one that want maintained anymore.

But either way, the open desktop shells are better than the proprietary ones.

It’s also a good example of how an open source project manages to outmaneuver big company offerings.

Home assistant just wants to make the stuff work. Whatever the stuff is, whoever makes it, do whatever it takes to make it work so long as there are users. Also to warn users when someone is difficult to support due to cloud lock in.

All the proprietary stuff wants to force people to pay subscription and pay for their product or products that licensed the right to play with the ecosystem. So they needlessly make stuff cloud based, because that’s the way to take away user control. They won’t work with the device you want because that vendor didn’t pay up to work with that.

Commercial solutions may have more resources to work with and that may be critical for some software, but they divert more of those resources toward self enrichment at the expense of the user.

And by extension, terminal emulators. Pretty much any open source one is miles better than the closed source ones.

Microsoft recognized this and has dramatically improved theirs as Microsoft terminal, an open source replacement. But it still isn’t as good as a lot of other terminals.

One day boss comes in and sees my colleague. Remarks how early he came in. He said he never left the previous day and planned to just keep working (salaried guy). Boss said he needed to take the day off, wouldn’t have him drive, and he drove his car and had me follow to take the boss back to work after dropping colleague and his car at home.

He consistently tried to break that guy’s incessant overworking. Had a lot of respect for him.

Unfortunately he got canned when he kept some stuff from upper management in writing that got upper management in trouble. Not enough trouble to remove their ability to retaliate, but enough to save a few other jobs of folks they were trying to throw under the bus for their mistake.

I understand it fine, and it’s not just a packaging phenomonon, all sorts of software developers have stopped trying to have consensus on platform and instead ‘just ship the box’. 99% of the time a python application will demand at least virtualenv. Golang, well, you are just going to staticly build (at least LTO means less unrelated stuff comes along for the ride). Of course docker style packaging is bring the whole distro. I’ll give credit to snap and flatpak that at least allow packaging to have external dependency packages to mitigate it somewhat.

I’d say actually a bit of the opposite. Generally speaking we don’t need a new package manager or init system, and better hardware support is almost entirely a kernel concern (one might make an argument that the loose bits of key management and tpm2 tools and authentication agents could be better integrated for “Windows Hello” type function I suppose, but I doubt that’s what the meme had in mind.

Not really needing to reinvent the wheel on those, we got a variety of wheels, sometimes serving different sensibilities, sometimes any difference in capability went away long ago (rpm/dnf v. deb/apt).

The best motivation I can think of at this point is to make specialty distribution that is ‘canned’ toward a specific use case. Even then it’s probably best to be an existing distribution under the covers. I think Proxmox is a good example, it’s just Debian but installer made to just do Proxmox. You want to do automated installation? Just use Debian and then add Proxmox (the official recommendation), because they have no particular insight on automated deployment, so why not just defer to an existing facility?

The biggest conceptual change in packaging has been “waste as much disk as you like duplicating dependencies to avoid conflicting dependencies”, maybe with “use namespace and cgroup isolation to better control app interactions” and we have snap, flatpak, appimage, and nix very well covering the gamut for that concept.

For init, we have the easy to modify sysv init, or the more capable but more inscrutable systemd. I don’t see a whole lot of opportunity between those two sorts of options already.

I assume a center beam supporting the platforms runs through all the platforms, obscured by the people.

Of course my terminals outnumber my browser tabs by about 3:1 right now. Commenting on an internet site needs neither scale nor complexity and a WebUI is fine for that.

Ironically, in Linux, if I ever see a Terminal, it’s because I opened it. If I’m doing stuff in GUI, terminals never pop up.

In Windows, doing stuff in GUI a blank terminal opens up and goes away during GUI interaction, or while executing background tasks occasionally.

Like I get and appreciate the CLI and for networking, that’s pretty much all I’m using anyway, but I am shocked that enterprise networking doesn’t even bother to do any GUI. Once upon a time Mellanox Onyx bothered to do a GUI and I could see some people light up, finally an enterprise switch that would let them do some stuff from a GUI. Then nVidia bought them and Cumulus and ditched their GUI.

There’s this kind of weird “turn in your geek card” culture about rejecting GUIs, but there’s a good amount of the market that want at least the option, even if they frankly are a bit ashamed to admit it. You definitely have to move beyond GUI if you want your tasks to scale, but not every engagement witih the technology needs to scale.

While you don’t need to memorize button locations and menus, the frustration is that it takes longer, and memorizing those details slightly mitigates. It’s torture helping someone do something while they hunt for the UI element they need to get to the next level of hierarchy. They will do it, in time, but it just feels like an eternity.

The main issue in GUI versus CLI is that GUI narrows the available options at a time. This is great, for special purpose usage. But if you have complex stuff to do, a CLI can provide more instant access to a huge chunk of capabilities, and provide a framework for connecting capabilities together as well as a starting point for making repeatable content, or for communicating in a forum how to fix something. Just run command “X” instead of a series of screenshots navigating to the bowels of a GUI to do some obscure thing.

Of course UI people have generally recognized the power and usefulness of text based input to drive actions and any vaguely powerful GUI has to have some “CLI-ness” to it.