Surely you can see that idea is a disaster to begin with. I mean, heavy traffic running on and wearing down expensive PV equipment... Those regions where it would work well are already sparsely populated, and could easily install more efficient PV units next to the road.
Exactly, it's great if you've got a house to risk. By the time people pay off their mortgage nowadays their bones will have turned to dust.
The baby boomers are sitting on most of the money, or act as VCs or angels to rip people off, so of course things'll have to be done differently by younger generations.
Containers have nothing to do with an inability to multitask. They're about, well, containing changes. That is, if I update glibc I don't have to worry about testing 47 different services on the host to ensure they all work before walking away. Instead I only have to test one, since that glibc is private to a single service. They do consume more RAM, of course, since less is shared in memory. That is the tradeoff.
As I said, they are just unnecessary bloat. The problem you are trying to solve is self-serving and endless.
let's say you need to update glibc, then you add containers, now you need to update your container software so you add container-containers, then next you need to update your container-container software, so you need container-container-containers.
No matter how long you keep up, you're still going to end up with the same problem and additional ones. But by now, the system has devolved into a slow mess that no one wants to touch. So you go and buy a new server and hope things are different this time.
The whole point of a robust design is that it makes errors harder to commit, and handles them better. If nobody wrote bad code we wouldn't need process memory isolation either.
Memory protection is a basic requirement for security in a multi-user environment.
That is the problem - the files are editable. That means that every time you update a package you have to re-merge the stock scripts with all your changes. With a systemd drop-in you can override a configuration setting without editing any file owned by a package.
Assuming there even is such a config setting in systemd, and that it works.
You can run scripts from a systemd unit if you need to, but the point is that 95% of the time you don't have to.
Problem is, for the most part people want to get rid of behaviour in systemd, which doesn't work for them or is otherwise useless. And in many cases it simply isn't possible.
You're basically arguing about the merits of procedural programming over declarative programming
Not really, both would work, but fewer people are good at declarative which means it's bad for system tools. I'm arguing flexible design over monolithic when it comes to something like init.
You never want to reboot for minor system changes, so init needs to be as flexible as possible, to accomodate any kind of change. Systemd, the monolithic binary that links all the way up to GUI layers. You'll need to reboot for just about every software update.
It really is the worst solution anyone could ever come up with for a problem that never existed in the first place.
I'm not sure I could come up with something more stupid.
You may look at things differently and therefore my response may sound harsh, but the way any normal *nix person sees these "improvements":
>1. Doesn't support being run in a container (though this is being worked on). Apparently it now does. But I couldn't care less since containers and virtualization are an exercise in bloated pointlessness. Most operating systems can already run multiple processes simultaneously. >2. Is slow to start up, which is important for containers. Slow startup is a result of huge scripts and their interpreters. You really can't have it both ways. >3. The network setup scripts could use improvement. No idea, never used the default ones. >4. It tends to leave orphaned processes lying around. Haven't seen this except in faulty scripts. >5. It doesn't care about exit status for anything. What should it do with it? It's a config issue. >6. It can't shut down without leaving read-only filesystemd mounted. This might be a bug >7. It takes quite a while to actually shut down. Again a config issue. >8. It lacks support for service monitoring. I assume you mean respawning? It's usually not a good idea, but openrc supports it. >9. Doesn't support minor tweaks to init script configuration like adding ionice without merging changes on every package update. Don't know what you mean, all the files are editable, and you're not supposed to just blindly replace config with defaults.
The point is, openrc (just like sysVinit) is a generic tool that doesn't make unnecessary assumptions about what you're trying to do with it and due to its scripted nature has no imaginary boundaries.
I can imagine using something similar but much less bloated than systemd for simple embedded devices, but not if it's made by Mr. Poettering & co. who have a long history of bad (and anti-unix) design decisions at every corner.
Because, despite it being for the elite, it's still a lot better and easier to use than the alternatives. Most people however, are switching to mobile handsets that run Android, and don't seem to need a full blown PC at all.
Most people don't care if Linux has a low market share, we think it's an advantage, keep the good users in and the trash out, and it's most certainly better the less Linux resembles crap like Windows, a system that will soon be remembered only by history books.
Users are only "good" if they are qualified enough to keep software working smoothly, instead of just whining.
I don't want Joe Average (assuming he's a retard like you put it) to be filling up support forums with junk because he can't RTFM.
I'm sorry, but an OS designed for your definition of "Joe Average" is an OS that would cause a mass exodus of anyone skilled enough to work on it. There are plenty of those, like Etch-a-sketch. Have you tried it?
1&2. GUI? A sysadmin is expected to know how to edit text files and use the console. 3. Auto-running executables by accidental click is a very bad idea. Especially for "Usability". It's configurable for more advanced users. 4. Seamless updates cannot be accomplished without killling programs that are running and running into config issues. The problem is that the program needs an update. 5. App store? so linux gets more of the shitty types of apps that phones have? 6. You are free to rename free software to your liking 7. How do you know someone wants to mount an iso? Maybe they want to record it on an optical disc? Or maybe they want to use it for a virtual machine? 8. Windows shortcuts are absolutely retarded, and should not be emulated when most *DEs already offered much better ones long before windows. 9. Ever tried typing "locate" or "find"? I think the problem is that you are using an indexed search, which for obvious reasons won't know what's not in the index.
You do not understand the Unix philosophy, since most of your suggestions are done differently on purpose. Learn how to work with a powerful and more secure system, or go back to your smartphone, it's probably more to your liking.
Don't blame others for your incompetence as a teacher, nor your low skill with programming and Linux.
Many kids become programmers at the age of 4 if just given the chance and the right tools. An old PC with Linux is great for learning, but a brand new Windows PC or an Ipad simply isn't, since they are entertainment devices, period.
Let's see, the number one most common reason to create a distro is "usability" and we've already got hundreds. Red Hat, Mandrake, Suse, Ubuntu to name a few. None of them became as usable as they claim.
Maybe there's something awfully wrong with that recipe, maybe usability comes as a result of other factors, such as choice, determinism, *nix philosophy or any number of other things, which these distros clearly don't focus on.
Stroustrup has just recently said that C is obsolete. Not that I care, C++ is his baby. But, is it in your opinion humble, to call the most popular language in existence obsolete?
"I also get upset by people needlessly sticking to C because they don't understand C++ very well. Your point?" Case in point. You think that people don't understand C++ if they don't prefer it for every project.
That's the core of why people dislike C++, it's not necessarily the language, it's the whole culture around it, which reeks of self-entitlement and navelgazing.
C++ may have been created as an extension of C once upon a time, but clearly people disagree on the benefits of C++ on some types of projects. I'd say that C++ tends to kill productivity on some larger projects because people get bogged down into arguments about language details instead of getting work done. And in this case kill is an understatement, because refactoring tends to make up half of commit history. C++ isn't helped by this hodge-podge pile of junk like stl and boost that people see as some form of standard library. Things like Qt had to come in and save C++ from early death, so things are starting to look up.
Anyhow, for low level code, C is much preferred because it doesn't hide things and that the developer culture is much more mature, often more skilled and result-oriented.
Java was not widely used when it was chosen, it eliminates good programming practices and it doesn't have a decent *anything*. It's really just evidence that langue du jour rules the day when it comes to decisionmaking no matter how utterly shit the language is.
You're of course correct. But if you look at the development of phone radios.. you'll see that the handsets are getting so over the top ridiculously complex, with like 30 different frequency bands, MIMO and at least 5 topologically different radio technologies. They need those 4 core CPUs in "smart" phones just to handle radio comms. Just try fitting all those antennas and other crap inside a watch.
It is feasible, (1-3yrs) just depends how smart your watch really is. These full blown PC-operating systems running on "watches" with full colour displays are obviously never going to have more than a few days battery time.
Because it's not the right solution for every problem, and if you make languages that *force* this kind of behaviour, the shitty programmer will just put their bugs elsewhere. The solution is to simply write better code.
That's not how it works, old solutions are still being used because they work incredibly well, and if not, they are improved. The younger engineer may not know that and sometimes gravitate towards advertised solutions.
When talking about development, in most cases there's nothing new under the sun. Programming languages and tools haven't really improved for the last 40 years. Most of the new stuff is simply hot air, has been tried before and failed, and the experienced developers know this. They also have the ability to more readily recognise when something truly is novel and an improvement. Development is one of those areas where age is clearly a massive factor in the quality/productivity of a worker since younger engineers have had less time to learn their job.
In terms of features and overall syntax. Details are unimportant when most new languages arguably are doing the same things as languages from 20-30 years ago.
I'm actually vehemently against using multiple languages, especially languages with large runtime requirements. We already have too much fragmentation of incompatible code libraries getting written in 300 different scripting languages. It's especially pointless when you realize there really is nothing new under the sun.
A language isn't just a tool. The situation is the equivalent of people writing down technical literature in Esperanto and everyone else picking their own language.
I'm sure everyone was thinking, we don't have enough languages that are basically a badly implemented subset of C++. We need to make another one. Let's see if Android will respond by creating an even less compatible C++ clone than Java.
Slashdot Mirror
Surely you can see that idea is a disaster to begin with. I mean, heavy traffic running on and wearing down expensive PV equipment...
Those regions where it would work well are already sparsely populated, and could easily install more efficient PV units next to the road.
Exactly, it's great if you've got a house to risk. By the time people pay off their mortgage nowadays their bones will have turned to dust.
The baby boomers are sitting on most of the money, or act as VCs or angels to rip people off, so of course things'll have to be done differently by younger generations.
Containers have nothing to do with an inability to multitask. They're about, well, containing changes. That is, if I update glibc I don't have to worry about testing 47 different services on the host to ensure they all work before walking away. Instead I only have to test one, since that glibc is private to a single service. They do consume more RAM, of course, since less is shared in memory. That is the tradeoff.
As I said, they are just unnecessary bloat. The problem you are trying to solve is self-serving and endless. let's say you need to update glibc, then you add containers, now you need to update your container software so you add container-containers, then next you need to update your container-container software, so you need container-container-containers. No matter how long you keep up, you're still going to end up with the same problem and additional ones. But by now, the system has devolved into a slow mess that no one wants to touch. So you go and buy a new server and hope things are different this time.
The whole point of a robust design is that it makes errors harder to commit, and handles them better. If nobody wrote bad code we wouldn't need process memory isolation either.
Memory protection is a basic requirement for security in a multi-user environment.
That is the problem - the files are editable. That means that every time you update a package you have to re-merge the stock scripts with all your changes. With a systemd drop-in you can override a configuration setting without editing any file owned by a package.
Assuming there even is such a config setting in systemd, and that it works.
You can run scripts from a systemd unit if you need to, but the point is that 95% of the time you don't have to.
Problem is, for the most part people want to get rid of behaviour in systemd, which doesn't work for them or is otherwise useless. And in many cases it simply isn't possible.
You're basically arguing about the merits of procedural programming over declarative programming
Not really, both would work, but fewer people are good at declarative which means it's bad for system tools. I'm arguing flexible design over monolithic when it comes to something like init. You never want to reboot for minor system changes, so init needs to be as flexible as possible, to accomodate any kind of change. Systemd, the monolithic binary that links all the way up to GUI layers. You'll need to reboot for just about every software update.
It really is the worst solution anyone could ever come up with for a problem that never existed in the first place. I'm not sure I could come up with something more stupid.
You may look at things differently and therefore my response may sound harsh, but the way any normal *nix person sees these "improvements":
>1. Doesn't support being run in a container (though this is being worked on).
Apparently it now does. But I couldn't care less since containers and virtualization are an exercise in bloated pointlessness. Most operating systems can already run multiple processes simultaneously.
>2. Is slow to start up, which is important for containers.
Slow startup is a result of huge scripts and their interpreters. You really can't have it both ways.
>3. The network setup scripts could use improvement.
No idea, never used the default ones.
>4. It tends to leave orphaned processes lying around.
Haven't seen this except in faulty scripts.
>5. It doesn't care about exit status for anything.
What should it do with it? It's a config issue.
>6. It can't shut down without leaving read-only filesystemd mounted.
This might be a bug
>7. It takes quite a while to actually shut down.
Again a config issue.
>8. It lacks support for service monitoring.
I assume you mean respawning? It's usually not a good idea, but openrc supports it.
>9. Doesn't support minor tweaks to init script configuration like adding ionice without merging changes on every package update.
Don't know what you mean, all the files are editable, and you're not supposed to just blindly replace config with defaults.
The point is, openrc (just like sysVinit) is a generic tool that doesn't make unnecessary assumptions about what you're trying to do with it and due to its scripted nature has no imaginary boundaries.
I can imagine using something similar but much less bloated than systemd for simple embedded devices, but not if it's made by Mr. Poettering & co. who have a long history of bad (and anti-unix) design decisions at every corner.
The question is what was wrong with OpenRC?
It's flexible enough to do just about all the useful tasks that sysV and that systemd does.
We really don't want a kernel in user space unless you want Linux to become infected with the finder syndrome of MacOSX.
No, it's just *your* definition of what easy to use is. Most of us don't agree, which is reflected in your unhappiness with the software.
I'm not saying free software GUIs are perfect, far from it, but they are in general a lot better and more usable than proprietary ones.
Because, despite it being for the elite, it's still a lot better and easier to use than the alternatives.
Most people however, are switching to mobile handsets that run Android, and don't seem to need a full blown PC at all.
Most people don't care if Linux has a low market share, we think it's an advantage, keep the good users in and the trash out, and it's most certainly better the less Linux resembles crap like Windows, a system that will soon be remembered only by history books.
Users are only "good" if they are qualified enough to keep software working smoothly, instead of just whining.
I don't want Joe Average (assuming he's a retard like you put it) to be filling up support forums with junk because he can't RTFM.
I'm sorry, but an OS designed for your definition of "Joe Average" is an OS that would cause a mass exodus of anyone skilled enough to work on it.
There are plenty of those, like Etch-a-sketch. Have you tried it?
1&2. GUI? A sysadmin is expected to know how to edit text files and use the console.
3. Auto-running executables by accidental click is a very bad idea. Especially for "Usability". It's configurable for more advanced users.
4. Seamless updates cannot be accomplished without killling programs that are running and running into config issues. The problem is that the program needs an update.
5. App store? so linux gets more of the shitty types of apps that phones have?
6. You are free to rename free software to your liking
7. How do you know someone wants to mount an iso? Maybe they want to record it on an optical disc? Or maybe they want to use it for a virtual machine?
8. Windows shortcuts are absolutely retarded, and should not be emulated when most *DEs already offered much better ones long before windows.
9. Ever tried typing "locate" or "find"?
I think the problem is that you are using an indexed search, which for obvious reasons won't know what's not in the index.
You do not understand the Unix philosophy, since most of your suggestions are done differently on purpose.
Learn how to work with a powerful and more secure system, or go back to your smartphone, it's probably more to your liking.
Don't blame others for your incompetence as a teacher, nor your low skill with programming and Linux.
Many kids become programmers at the age of 4 if just given the chance and the right tools.
An old PC with Linux is great for learning, but a brand new Windows PC or an Ipad simply isn't, since they are entertainment devices, period.
Computer hardware manufacturing is probably one of the most expensive things, environmentally speaking, in the world.
Reusing a PC, even if it uses 2000% more energy, and requires transportation across the world, is still a net benefit to our globe.
We need more of this, and less new hardware.
Elementary, my dear Watson.
Let's see, the number one most common reason to create a distro is "usability" and we've already got hundreds. Red Hat, Mandrake, Suse, Ubuntu to name a few. None of them became as usable as they claim.
Maybe there's something awfully wrong with that recipe, maybe usability comes as a result of other factors, such as choice, determinism, *nix philosophy or any number of other things, which these distros clearly don't focus on.
Stroustrup has just recently said that C is obsolete.
Not that I care, C++ is his baby. But, is it in your opinion humble, to call the most popular language in existence obsolete?
"I also get upset by people needlessly sticking to C because they don't understand C++ very well. Your point?"
Case in point.
You think that people don't understand C++ if they don't prefer it for every project.
That's the core of why people dislike C++, it's not necessarily the language, it's the whole culture around it, which reeks of self-entitlement and navelgazing.
C++ may have been created as an extension of C once upon a time, but clearly people disagree on the benefits of C++ on some types of projects.
I'd say that C++ tends to kill productivity on some larger projects because people get bogged down into arguments about language details instead of getting work done. And in this case kill is an understatement, because refactoring tends to make up half of commit history.
C++ isn't helped by this hodge-podge pile of junk like stl and boost that people see as some form of standard library. Things like Qt had to come in and save C++ from early death, so things are starting to look up.
Anyhow, for low level code, C is much preferred because it doesn't hide things and that the developer culture is much more mature, often more skilled and result-oriented.
C++ proponents aren't very humble, neither is the language itself.
I also get upset with people constantly trying to shove C++ on top of C projects, just because they don't know C very well.
Java was not widely used when it was chosen, it eliminates good programming practices and it doesn't have a decent *anything*. It's really just evidence that langue du jour rules the day when it comes to decisionmaking no matter how utterly shit the language is.
Yeah let's switch from one annoyingly shitty language to another.
Seriously, these are the worst languages ever invented, with absolutely zero redeeming properties.
You're of course correct.
But if you look at the development of phone radios.. you'll see that the handsets are getting so over the top ridiculously complex, with like 30 different frequency bands, MIMO and at least 5 topologically different radio technologies. They need those 4 core CPUs in "smart" phones just to handle radio comms.
Just try fitting all those antennas and other crap inside a watch.
I'd say 6 months is the minimum battery time for a device to be called a watch and not a wristband-PC.
It is feasible, (1-3yrs) just depends how smart your watch really is.
These full blown PC-operating systems running on "watches" with full colour displays are obviously never going to have more than a few days battery time.
Because it's not the right solution for every problem, and if you make languages that *force* this kind of behaviour, the shitty programmer will just put their bugs elsewhere.
The solution is to simply write better code.
That's not how it works, old solutions are still being used because they work incredibly well, and if not, they are improved.
The younger engineer may not know that and sometimes gravitate towards advertised solutions.
When talking about development, in most cases there's nothing new under the sun. Programming languages and tools haven't really improved for the last 40 years.
Most of the new stuff is simply hot air, has been tried before and failed, and the experienced developers know this. They also have the ability to more readily recognise when something truly is novel and an improvement.
Development is one of those areas where age is clearly a massive factor in the quality/productivity of a worker since younger engineers have had less time to learn their job.
In terms of features and overall syntax.
Details are unimportant when most new languages arguably are doing the same things as languages from 20-30 years ago.
I'm actually vehemently against using multiple languages, especially languages with large runtime requirements.
We already have too much fragmentation of incompatible code libraries getting written in 300 different scripting languages.
It's especially pointless when you realize there really is nothing new under the sun.
A language isn't just a tool. The situation is the equivalent of people writing down technical literature in Esperanto and everyone else picking their own language.
I think you like recursive solutions.
I'm sure everyone was thinking, we don't have enough languages that are basically a badly implemented subset of C++. We need to make another one.
Let's see if Android will respond by creating an even less compatible C++ clone than Java.