Well it hasn't helped that we have had a generation or two of marketing saying that you don't need to know anything to operate a computer.
Computers may well be the most complex things humanity has constructed, yet the claim is that the interfaces can be refined so much that a infant can operate them unassisted.
A big glaring difference between the C64 of old and the "dev kit" of today is that you have to flip "the switch".
With the C64 the command prompt was also the BASIC interpreter. You could enter the command to load other files into memory, and be on your merry way, or you could start entering BASIC code right there.
You see something similar with *nix shell script.
But with this "dev kit" you have to make the device enter a specific mode. And likely this mode will block you from accessing any of your gaming for the duration.
You have something similar on Chromebooks, where there is a "developer switch". Flipping that switch (from user to developer or back) will wipe the device clean.
If this was the case of the C64, it would have required that some Commodore rep came to your house, searched your belongings, confiscated any and all programs, and then set your C64 into "developer mode".
Indeed, the boot aspect of systemd has long since "matured". the feature creep happening now is very much about "cloud" and containerization.
An area that happens to be a stated target market for RH moving forward.
And may be why other distros are adopting systemd, as it is likely to become THE basis for Linux (cloud) servers going forward. Especially when backed by the 800 pound gorilla of the Linux ecosystem.
Not a GPU in the modern sense, as it lacked any kind of 3D acceleration. And you could get ATI boards for PC that did similar acceleration to what the Amiga chips did.
Hard to debug in the sense that rather than having scripts that call commands i can run manually to see how they behave, it is all now dbus messages bouncing back and forth inside dbus-daemon.
All of those however only really function if systemd is running as pid.
And frankly i think the logind element is what got people sitting up and paying attenotion. I certainly did. Because it replaced consolekit. And while consolekit could live on top of any odd init, logind is wedded to systemd as pid1.
And quite a number of freedesktop systems that previously relied on consolekit to privide session and seat tracking now depend on logind. Thus if you want to get your external drive mounting (and who knows what else) working, you need logind, and thus you need to be running systemd as init.
Best i can tell, the messages simply do not show up inside journald. And there is no way for them to make it onto the terminal when run inside systemd.
Mind tough that it is a issue that appears to be fixed in more recent version of systemd, but RH elected to ship a older version in RHEL7.
I find myself reminded of a recent-ish article where someone tried to install Ubuntu on a Lenovo workstation, and found that the UEFI would only accept two partion labels. That was Windows and RHEL. It would happily boot Ubuntu when the label was changed to RHEL, and things works just as well, but it does make one stop and wonder about the position RH holds these days...
Watching that is just as likely to drive people away, as the attitude of the presenter is up there with the one displayed by the systemd maintainers...
The major think breaking said transparency was that everyone and their dog wanted to use OGL for something, and bypassing X by talking straight to the hardware and dumping the result as a bitmap into X again.
This approach is by its very nature not network transparent, as it assumes that the program code lives on the same machine as the hardware used to draw the result.
there are implementations for doing this over the network, but nobody seemed interested in adopting it.
Sadly i think that after Poettering went live with his rant about the Linux community, the whole systemd issue has turned into a "gamergate" style shit storm.
Best i can tell, you can use Wayland as a display driver for Xorg (THE X server right now, iirc).
Frankly that is the way i see myself using Wayland, as basically a way to render the whole X session using OGL. This instead of using X as a "minimal" container for a OGL "window".
>As cluttered and dated as SysV is at least you don't have to take pieces of it apart to change what flags are being used to call some secondary command at boot time.
And that may be touching on a big issue. sysv en its like was created in an era where you could not easily spin up another server as needed, and doing a full reinstall for a "minor" issue was seen as insanity.
Thus systems that could be fixed in place, with minimal tools, where the order of the day.
Now however we have a generation that has grown up accustomed to doing reinstalls at the drop of a hat, thanks to desktop computers. And their server environment makes heavy use of virtual machines and containerization. Neither of these are conductive towards a mentality of fixing issues in place, never mind making sure they stay fixed.
In essence they are doing service uptime via machinegun, not belt and suspenders engineering. Who cares if a instance crashes, there are 1000s ready to take over, and it will be rebooted in seconds anyways.
And that may be what is driving this new, wider, definition of autism forward.
Where before your kid and other kids would survive in some fashion in a local community because everyone was expected to be somewhat self-sufficient (maybe not a grand life, but a survivable one), now everyone is expected to bend over backwards for some "persona" to get their gruel tokens. And if you don't bend like they want you do, it is game over.
So the whole push about "normal" is newspeak for "don't rock the boat!".
Slashdot Mirror
Well it hasn't helped that we have had a generation or two of marketing saying that you don't need to know anything to operate a computer.
Computers may well be the most complex things humanity has constructed, yet the claim is that the interfaces can be refined so much that a infant can operate them unassisted.
Sorry, but we can't have it both ways...
A big glaring difference between the C64 of old and the "dev kit" of today is that you have to flip "the switch".
With the C64 the command prompt was also the BASIC interpreter. You could enter the command to load other files into memory, and be on your merry way, or you could start entering BASIC code right there.
You see something similar with *nix shell script.
But with this "dev kit" you have to make the device enter a specific mode. And likely this mode will block you from accessing any of your gaming for the duration.
You have something similar on Chromebooks, where there is a "developer switch". Flipping that switch (from user to developer or back) will wipe the device clean.
If this was the case of the C64, it would have required that some Commodore rep came to your house, searched your belongings, confiscated any and all programs, and then set your C64 into "developer mode".
I fear it will take more than a pill to stop jocks from being, well, jocks...
Says that he resigned back in 2009.
And hmm, Collabora. I keep bumping into that company for some reason...
Egg on my face indeed...
Indeed, the boot aspect of systemd has long since "matured". the feature creep happening now is very much about "cloud" and containerization.
An area that happens to be a stated target market for RH moving forward.
And may be why other distros are adopting systemd, as it is likely to become THE basis for Linux (cloud) servers going forward. Especially when backed by the 800 pound gorilla of the Linux ecosystem.
Not a GPU in the modern sense, as it lacked any kind of 3D acceleration. And you could get ATI boards for PC that did similar acceleration to what the Amiga chips did.
https://en.wikipedia.org/wiki/...
And that is why i don't have a sound notification set up on my email client.
Seeing that the icon had changed is more than enough of a indication.
Hard to debug in the sense that rather than having scripts that call commands i can run manually to see how they behave, it is all now dbus messages bouncing back and forth inside dbus-daemon.
At this point init is a distraction.
At present time systemd cotains code for:
DHCP client
DNS client
Cron replacement
Firewall management
Inetd
Network management
Logind
Udev
And likely a fair bit more that i forget.
All of those however only really function if systemd is running as pid.
And frankly i think the logind element is what got people sitting up and paying attenotion. I certainly did. Because it replaced consolekit. And while consolekit could live on top of any odd init, logind is wedded to systemd as pid1.
And quite a number of freedesktop systems that previously relied on consolekit to privide session and seat tracking now depend on logind. Thus if you want to get your external drive mounting (and who knows what else) working, you need logind, and thus you need to be running systemd as init.
Turtles all the bleeping way down...
Best i can tell, the messages simply do not show up inside journald. And there is no way for them to make it onto the terminal when run inside systemd.
Mind tough that it is a issue that appears to be fixed in more recent version of systemd, but RH elected to ship a older version in RHEL7.
https://en.wikipedia.org/wiki/...
Not just computers. Supposedly the ipod shipped with a equalizer tuned for Jobs aging hearing.
I find myself reminded of a recent-ish article where someone tried to install Ubuntu on a Lenovo workstation, and found that the UEFI would only accept two partion labels. That was Windows and RHEL. It would happily boot Ubuntu when the label was changed to RHEL, and things works just as well, but it does make one stop and wonder about the position RH holds these days...
low level GUI plumbing. It is X without the networking stuff, and assumes you have a GPU to play around with.
Watching that is just as likely to drive people away, as the attitude of the presenter is up there with the one displayed by the systemd maintainers...
The major think breaking said transparency was that everyone and their dog wanted to use OGL for something, and bypassing X by talking straight to the hardware and dumping the result as a bitmap into X again.
This approach is by its very nature not network transparent, as it assumes that the program code lives on the same machine as the hardware used to draw the result.
there are implementations for doing this over the network, but nobody seemed interested in adopting it.
Sadly i think that after Poettering went live with his rant about the Linux community, the whole systemd issue has turned into a "gamergate" style shit storm.
It seems to boil down to this behavior having changed, for the better, with more recent systemd versions. But RHEL is using a "old" version.
One may well think of the relationship between RHEL and Fedora as similar to the one between Ubuntu and Debian.
Fedora is as close to bleeding edge as you can get without going rolling release, and a major testbed for what RH will put into RHEL down the road.
Also means that if you can get your project to become part of the Fedora install set you have pretty much made it...
Best i can tell, you can use Wayland as a display driver for Xorg (THE X server right now, iirc).
Frankly that is the way i see myself using Wayland, as basically a way to render the whole X session using OGL. This instead of using X as a "minimal" container for a OGL "window".
Actually that bug may already be fixed upstream, and the proper place to report it is to RH bugtracker.
Basically, RH has used a "old" systemd version for RHEL7.
Sadly these kinds of issues muddy the water regarding systemd critique, as it allows blanket dismissal of complaints...
Never mind that you can load the smaller ASMs onto just about anything...
https://en.wikipedia.org/wiki/...
>As cluttered and dated as SysV is at least you don't have to take pieces of it apart to change what flags are being used to call some secondary command at boot time.
And that may be touching on a big issue. sysv en its like was created in an era where you could not easily spin up another server as needed, and doing a full reinstall for a "minor" issue was seen as insanity.
Thus systems that could be fixed in place, with minimal tools, where the order of the day.
Now however we have a generation that has grown up accustomed to doing reinstalls at the drop of a hat, thanks to desktop computers. And their server environment makes heavy use of virtual machines and containerization. Neither of these are conductive towards a mentality of fixing issues in place, never mind making sure they stay fixed.
In essence they are doing service uptime via machinegun, not belt and suspenders engineering. Who cares if a instance crashes, there are 1000s ready to take over, and it will be rebooted in seconds anyways.
Consumerism has reached the server rack...
And that may be what is driving this new, wider, definition of autism forward.
Where before your kid and other kids would survive in some fashion in a local community because everyone was expected to be somewhat self-sufficient (maybe not a grand life, but a survivable one), now everyone is expected to bend over backwards for some "persona" to get their gruel tokens. And if you don't bend like they want you do, it is game over.
So the whole push about "normal" is newspeak for "don't rock the boat!".