That is technically true, but literacy tests, poll taxes and other voter suppression methods were legal until 1965. They had the right on paper, but not in practice.
> That is technically true, but literacy tests, poll taxes and other voter suppression methods were legal until 1965. They had the right on paper, but not in practice.
That's making my point for me, all those imbeciles in Qanon were so detached from reality after being propagandized on Facebook by the CCP, Cambridge Analytica et al into thinking that they should vote for Trump or the World would fall apart, only to be left to question their false reality when the results didn't favour their outcome so they did what all disfranchised do when they feel the system is not on their side (which has historically favoured whites in the US), riot.
My point stands, and that is that things have gotten past a melting point because no one wants to exit their insulated echo chambers they've resided and then were forced into during COVID rather than get involved and do the heavy lifting that it takes make actual progress.
Political means is just one way by which effective change occurs at the local level, I didn't vote in the primary despite being told the red wave was imminent (which means nothing to me as I think it's a false dichotomy): but I have residence in a blue state and instead I took the time to volunteer locally and hand out food for those in need instead. It was a better use of my time and helped lessen misery, if only for a sort period, by feeding people.
Moreover, do you know he actual voter participation rate in the US presidential election in 2016/2020? Do you know the demographics, and how few below 40 are actually voting? You speak about race and gender, when you really should be looking at how few non-boomers are involved in politics at all to see how alarming it really is.
> My point stands, and that is that things have gotten past a melting point because no one wants to exit their insulated echo chambers
including you because your descriptions are not at all why people voted for Trump.
The guy publicly stood in front of a bunch of businessmen who were planning on taking more manufacturing overseas and told them if they did so he was going to tax the shit out of their imports.
In the late 90's people started ordering drugs from Canada, websites started popping up allowing it. Until it was made illegal to do because these Canadian drugs weren't approved by the FDA (just by the Canadian version of it).
Trump got rid of that law. None of the democratic presidents, including Obama, were willing to do it.
Everyone always thinks their bubble is the non-bubble.
> Everyone always thinks their bubble is the non-bubble.
His tariffs were a joke, I remember the one's he was threatening to put on wine, cheese and meats from EU and that still wouldn't have been enough to offset the immense national debt because the US simply doesn't have the the QC/QA to compete with some of their goods. And he gave concessions to large corps who subsequently were using illegal labour in the US--this was clear during COVID when all the migrant workers were getting sick and meat packing plants and with seasonal farm hands during harvest as he threatened to stop migration, which still affects people who have been here already to this day in the H1-N process.
But I concede that their were more factors to it than those, no including the grift and Q-Anon BS, but honestly it's not worth the time.
I can remember way back around 1990 being told that waterfall was mostly a bad idea, and few shops really followed it. Rapid prototyping was agile back then. We were shown how to produce flow charts and static call diagrams in Software Engineering 201 or whatever it was called, and I felt they were doing it to show us how but also to demonstrate how much work it was, and how easy it was to get the analysis wrong.
As new fashions arose, instead of attacking waterfall as practiced (which, don't get me wrong, is still labor intensive), they criticized a straw man version, because it made the new methods look even better.
Sounds like CentOS Stream will bring the pain to users and admins. Going forward, the answer to every stability question will be "maybe you should go buy Redhat".
I had a bad feeling about the CentOS project when Redhat became involved as more than an upstream RPM source. I hope CentOS isn't turned into another Fedora.
I'm sure many of you will be happy to tell me that I'm wrong. Please do.
As someone who actually likes the new behaviour[+] would you mind elaborating why you dislike it so much? The only case I can think of is copying filenames into a GUI or something which doesn't support escaped paths, but the previous behaviour wasn't much better because you couldn't be sure what the full filename was.
[+]: Imho it makes it easier to copy-paste paths (sometimes I need to , as well as spot whitespace / strange characters in filenames.
It's not about liking the behaviour, it's about the usual UNIX nonsense of arbitrary breaking decisions being made on the hoof for whimsical reasons - everywhere. Because no one cares enough to cooperate with others on these things outside of their own little sandpit.
Path handing is an important feature. It should be standardised and predictable. It doesn't even matter how it's standardised. What matters is that everyone uses the same system so there are no random surprises or thwarted expectations.
In a robust OS everything would be a lot more interoperable and standardised than it is in UNIX. Being able to pipe things around is not the killer feature it might be - not if you have to waste time pre/post translating everything for arbitrary reasons before you can do anything useful with it.
The main way you'd be interoperating with ls is through pipelines, and GNU ls doesn't do any pretty-printing of paths when used in a pipeline (besides, arguably the correct way of handling paths that may have newlines or spaces embedded is with `find -print0` but that's a whole different topic). Or is there some other aspect of interoperability you're referring to?
But if we're being honest, path handling (as well as structured data) in shell scripts and pipelines has always been of the largest trash-fires in Unix -- while I don't personally like how Powershell solved the problem on Windows at least they tried to solve it.
If you use open source software long enough, you will eventually be disappointed in a design decision. In this case, it was a big surprise when a tool I'd been using since the early 1990s suddenly changed its output with absolutely no warning. This is both an expected result from using Gentoo, and simultaneously very disappointing.
Furthermore, I was disappointed by the reaction from both the developers and other people leaping to their defense who felt that they'd been personally insulted by users suggesting that this may have been better as a non-default option. If I can set QUOTING_STYLE=literal everywhere, surely the distro maintainers who wanted this could have set QUOTING_STYLE=shell-escape?
I'd be the first to say that everyone is free to disagree with me. I have the source, I have a workaround, I adapt.
I have been disappointed in FOSS design decisions before, but I've also been on the other side of such decisions as a maintainer -- and it's often the case that users aren't aware of all of the trade-offs that go into making "obvious" decisions. I try to be more understanding these days as a result -- yes, sometimes maintainers are wrong but all things being equal they probably know better than you or I what the right decision is.
For instance, one could argue that hiding the behaviour behind a flag makes the feature effectively useless (users that would benefit most from it would never know about the flag, and users who know enough to find the flag probably know about `find -print0` too). Punting the problem to distributions just means that everyone who is against the feature on general principle will now hound distributions for making the change (probably making arguments like "why are you making yourself incompatible with Debian X or Ubuntu Y.Z?") -- and will also result in the feature being unused and thus useless.
Now, is that enough of a reason to make a change to the default behaviour? I don't know, but to me it doesn't seem as though the right decision was "obvious". And again, the behaviour is only different when the output is displayed on an interactive terminal -- so the only breakage is the interface between the screen and your eyes.
> Very neat to see it on the storage side, and something I don't think anyone could fathom back in the spinning disk days.
Seagate had a product called Kinetic that was an Ethernet-connected key-value spinning disk. We had a 1U box with a number of 4000GB drives in our lab for an evaluation.
It was interesting but we didn't find a use for it. Product is dead now as far as I know.
All of a sudden everybody and his dog requires systemd or upstart or whatever flavor of rebranded and upgraded and extended and whatnot initd of the day.
I failed to see a reason behind this movement except of the "you're an old fart and this is how we're doing it today" explanation. And when BSD comes up and say this is not portable, everybody say we're on Linux and we don't care and you should jump the shark as we do. What?!
I think the newer alternatives are more standard, easier to understand, easier to write for my own services, and less error prone than sysvinit scripts. You may disagree with all of those points, but it really isn't a "you're an old fart and this is how we're doing it today" explanation. By all means, argue against the specific reasoning, but claiming there is none and it is just progress for its own sake is spurious.
I believe he meant "more standardized". I find that working with systemd is more predictable than with sysvinit and things that I expect to be able to do work as I expect them to work.
Ahhh like "more formally defined". Interesting. I've not run in that particular problem with svsvinit in the last couple decades, so I didn't see the synonym.
Loads of sysvinit scripts are distribution specific. With systemd, these are now shipped upstream. No clue what your problem is, but there are loads of benefits to systemd, suggest to try it out (and then recent version, not some old Fedora).
If the startup scripts are upstreamed and standard then the init system should be standard. Systemd is not standard because it relies on Linux kernel specific semantics.
BSD or any other kernels are left with no updated userland because they don't implement the same semantics.
You realistically expect BSD to ever use a GPL licensed init system? I don't see the point of systemd being able to run under BSD. BSD wants to get rid of every GPL licensed software, including GCC. You really expect them to consider switching their init system.
Aside from this, standard has nothing to do with Linux only or not. E.g. Microsoft Office is a de facto standard, it only runs on Windows and a not exactly the same version is available on Mac OS. Not on Linux, not on BSD. The file format is a standard.
Firstly, SystemD is licensed under the LGPL so it's not as viral.
Secondly, they've already changed project licenses before in 2012. Should the need arise to switch over to a more permissive license, they could ask again and strip out the code the can't get permission to change.
Perhaps it's for the same reason there would be no (FOSS) Intel or Radeon support, due to the FreeBSD kernel lacking features needed by those drivers.
However in FB9 they did get around to supporting KMS and are in the process of porting the latter over with the former already working.
My only concern would be if the developers flat out said no about going with a more permissive license, although I don't really see why they would do so as it is a program with limited applications outside of its intended role.
Sure. Don't get me wrong, I can write scripts to work with sysvinit too, but there's a lot more reading and cookbooking involved. I haven't had the same issue with systemd or upstart.
There's no equivalent for /usr/share, which some programs depend on. You could make /share, or you could just use /usr for everything and have it available at early boot. Putting everything "system" in /usr/ also lets you make backups more efficiently instead of having to blacklist /home/, /sys/, /proc/, etc.
The initd needs to depend on the kernel. POSIX semantics aren't enough. Even Upstart and SysV init change their behavior based on the kernel.
Furthermore, it makes sense for the responsibility of services to be delegated to one place, otherwise you end up in this situation where programs are started differently from cron than they are from /usr/bin/service than they are from init. It makes sense to delegate all the complex service management and watchdog stuff to one location, and that requires kernel-level semantics. For instance, systemd's use of cgroups allows CGI that it forks off to be killed when it tries to stop Apache.
I may be misreading you, but I think you're trying to ask why the survey was making technical decision justifications based on purely subjective opinions rather than a survey based on objective facts, balancing the cost to humanity of the few remaining /usr splitters having to reconfigure, vs the slightly increased effort of the very small number of people who write initscripts having to continue to use the old system plus or minus the increased effort by the existing stock of programmers having to learn systemd which the other distros having switched has been forced on everyone anyway. I think both sides of the balance have pretty small numbers.
A la the famous Landley rant from about 4 years ago, I had a NFS mounted /usr... back in 97 as an experiment which I rapidly terminated. Shared and RO /usr is an interesting hack, but probably not worth holding init development back, especially since so many other boot time things demand /usr anyway now (like the pulseaudio, like the networkmanager thing)
If you were aiming more at why systemd needs different stuff, you can google for Landley's email around 2010 on the topic and on the other side google for read only /usr and NFS /usr. Also google for cgroups, especially systemd and cgroups.
I'm saying that just because a bunch of people say they have a new shine thing, I should not be _forced_ to use it. They are free to do whatever they want as long as they don't force me on their bandwagon.
BSD should not have to implement Linux semantics just to start the userland.
You will never be forced to use systemd. You may have to stick with running debian 7 forever and backport your own bugfixes though :P
Unless you're suggesting that developers forcing users to upgrade is bad; users forcing developers to continue providing support for deprecated software forever is good?
> BSD should not have to implement Linux semantics just to start the userland.
If neither BSD nor Linux supported files, and then Linux added support for files, would you suggest that we refrain from making file-based software, and continue giving all apps raw disk access for sake of compatibility?
Using cgroups for service management is that kind of fundamental good idea - the BSDs don't have to copy the linux API, but they should really provide something similar
Sure, you can browse the web with IE5; if all your favourite sites work with it and they aren't changing, then you wouldn't see any reason to change either.
Meanwhile, a fairly significant number of people would like to be able to use the features in CSS3 / HTML5 - and while 75% of those features can be emulated in IE5 (with several megabytes of javascript libraries and terrible performance), life is easier and better all round if the users upgrade their foundations once in a while.
> BSD comes up and say this is not portable
systemd doesn't care about the kernel per se, only which features it provides. If they want to provide a cgroups-like API (which they should, because it's a great idea in and of itself), then I expect systemd will be ported to it fairly quickly.
Sticking to Gentoo for my personal systems (for many reasons, not just this issue). Slackware was my OS of choice once upon a time (there weren't many choices back then, though.)
