Ah, yeah, I've been reading around and I have to agree, the 40k must be a typo or something. So it sounds like these kinds of passes are something like 1/megayear. That doesn't make them exactly very likely to let you spread your civilization all that much, does it? I mean if you have a planning horizon of millions of years and have been around that long I'd expect a trip of 3-5 light years wouldn't be completely infeasible.
Exactly. Something like a fusion reaction energizing a VASIMIR-like magnetic nozzle choked down to a small diameter would produce a very high specific impulse (IE very fast exhaust velocity). You might also utilize gravity assist, but that would only be worth a fairly small increment of extra velocity (perhaps a Solar gravity assist would work, stealing some energy from the Sun's orbit around the galaxy, this could be possible though I don't know if it would be a good idea or not).
As far as the Voyager comment goes, they are going as fast as we could possibly get something moving at the time given the tech and navigational constraints. Its possible to attain somewhat higher velocities, but not a LOT higher with chemical rockets. Fusion power in the sense of a really efficient controlled fusion power source is not 'Star Trek' tech however. Its maybe 100 years out tech, but nothing new is required in terms of physics, etc. A fission rocket could actually work too, something like the Daedalus pusher-plate bomb concept could essentially be built today. It would be less efficient than some sort of advanced gas-core reactor, but we have not yet worked out how to build those either (easier than fusion probably, but not by a lot).
I feel confident that some pathway exists to say 100 AU/year velocities, which is enough for Oort Cloud type exploration, beyond that it is all very speculative though. There are plenty of concepts that can get to 8,000 AU, laser sails, fission/fusion, etc.
HIP 85605 will come within 8,000 AU of the Sun, still quite a distance, but VASTLY less than 3 light years. The blurb was also incorrect, this close pass will be in about 40k years, not 250k or more as stated (though perhaps this is a difference in sources, I don't know). 8,000 AU is something we could probably bridge with some advanced tech. For scale Voyager 1 is now at approximately 200 AU after 36 years of travel time, meaning it will take just shy of 2,000 years to reach this distance. It is certainly feasible to build a larger craft and fly it at 50x this speed using say fusion power, still only a very tiny fraction of C but yielding a trip time on the scale of a human lifetime. A little beyond our current engineering, but something similar to Daedelus, for instance, would suffice.
So, the idea isn't crazy. Its not that big a stretch of the imagination to think that true interstellar travel in the classic sense is simply infeasible. In fact it really is fairly difficult to imagine from an engineering perspective, there are technical issues so vast that they may well be insoluble, or only solvable by making compromises that are just not acceptable or limit such travel to very infrequent probes or something. That would leave close approaches as the single exception.
Hey, ALL 60's cars were deathtraps! The OP never said anything about it had to be safe. Not sure why you hate on the '66 though, its a very classic model. The disc brakes were pretty much crap, but you can easily fix that (and by now if you own such a car it has long since been dealt with). The drive train in the performance model is pretty much standard Ford. The Windsor HiPO with the 4 barrel is a pretty nice engine.
Its just introducing another dependency. While I agree that shell scripts aren't the most elegant thing in existence and you could certainly write better ones in say Perl that would just mean that everyone would have to install an interpreter, just to boot their machine, and I think that wouldn't go over too well. Shells are unavoidable, so that dependency is pretty trivial.
Beyond that you can certainly write some perfectly nice shell scripts, and it should be possible to hide whatever ugliness there is with some more extensive libraries. Shell scripts allow for includes of packages of routines, and RedHat did a lot of work in that direction way back when. I guess they just had better things to do and it was never pushed to its limits. As I said before there are also/etc/sysinit scripts which are intended to contain ALL the user-settable configuration parameters for system services. Again, this hasn't been pushed hard, probably because its just not glamorous work.
Frankly I think if someone put their mind to it they could clean up the existing sysVinit process, init itself, build some libraries and establish some better conventions and you'd have 75% of the benefits of systemd without all the ruckus. The other 25% most people can probably live without and its not at all clear to me it belongs in the same project. Much of it could exist as stand-alone tools/libraries and some better conventions covering how to use cgroups and etc. That would IMHO have been a better approach.
Using script files to setup and manage daemons because init is so primitive like SysVinit is, is simply a bad idea.
I'm sorry, but just saying "X is 'primitive'" isn't actually very useful. There is nothing primitive about scripts.
Also this isn't about SysVinit, this is about systemd. Picking at the one isn't an argument for the other. In fact SysVinit is pretty sophisticated in its own way, but its fine if we make it better or replace it with something BETTER. Again, just pointing out the problems with it isn't automatically enough to make systemd the correct alternative. I've pointed out negatives about the systemd approach, you need to address those.
Mixing executable code and declarative config statements like script based init systems do, is simply indefensible; it makes it hard to parse for both humans and machines.
There are two problems with this statement. First of all properly written init scripts ala RedHat put all their config in/etc/sysconfig, not mixed into any script. This is a perfectly easy practice that has been the state of the art for at least 10 years. Secondly blanket statements decreeing what is and isn't 'indefensible' are ridiculous. You need to make concrete arguments, I and many others are FAR past the point where any sort of decrees like this mean squat to us. There are many cases where basic invariant configuration elements are perfectly reasonably placed within a script. These are things that are not going to be changed in your installation but should be parameterized as good PROGRAMMING practice. Don't confuse those with configuration options that the system's user is going to want to change, they are very different things.
No one would ever design an init-system these days that didn't use pure text files for daemon config. SysVinit and similar are relics from a time when computing was done in a completely different way than today.
I am not trying to be disrespectful here for the pioneers that made various OS's back in the 1960's, 1970's and 1980's. It is just that some of the design choices they made, reflected the contemporary problems they had.
They made some simple but very flexible init systems based on shell scripts. But the simplicity just showed all kinds of problems over to the user space developer side, like handling dropping privileges when a daemon needed a low number port etc. And many people, including me, have long been of the opinion that such init-systems have been obsolete for years (if not decades). Most if not all certified Unix vendors have replaced their script based init systems (SMF and launchd are major inspiration init systems for systemd).
Horse Petunias. Computing hasn't fundamentally changed, and the same use cases that existed back in the mid 1980's when init systems in use today were birthed exist today. Believe me, I was there, and I know. A machine room today is solving the same problems that they were back then. Some of the technology is different and there are obviously some new things, but my 1980's Sun Unix machines ran pretty much like my Linux servers do today. If you want to tell me that a mobile phone is quite different from a mini-computer, well yes. However nobody is asserting that a mobile phone should be running the same init system as a web server, except the people making everything depend on systemd....
As I've said elsewhere in this thread you are failing to understand good overall system design and factoring if you think a large complex program that incorporates every behavior into itself and puts only configuration options into files is 'superior'.
I do think I understand enough about how OS's work to have a qualified opinion. We just happen to disagree about some things and is having a civilized exchange of arguments.
I don't know what 'SCO' has to do with it. Tandem wasn't SCO, they were supplying their own NonStop solution into the financial industry, which drove DEC's VAX cluster solutions clean out of that space. They were acquired by HP in 1997. I know because I was and still am friends with a number of the DEC engineers who worked in their clustering group in the late 80's and early 90's.
Linux had nothing in the way of traction in the workstation market in the 90's, it was not a player at all in any commercial sense. There was a very limited use of Linux on Multias by DEC as a way to make a cheap XTerm out of a failed workstation product, that was about it. Workstations at that time were heavily dominated by SGI with IBM, DEC, SUN, and some smaller 3rd party Alpha and MIPS system resellers. Many of those were NT 4.0 based boxes. I know people who used these things, sometimes 1000's of them, none of them ran Linux on them, it was unheard of. They were almost entirely used to run specific commercial applications (CAD, 3D software like Lightwave 3D, etc) which were rarely, if ever, ported to Linux (for instance there were some custom ports of Adobe products, which certainly shops had access to around this time, but they were never made widely available even to Adobe's bigger clients).
BSDs were indeed quite popular in the hosting space in the early-mid 90's. Linux eventually eclipsed BSD in most shops by around '97, but particularly in the 93-94 time frame there were significant issues with using Linux in Line-of-business server applications. I should know, I was a significant supplier to and engineer of commercial web solutions, local ISPs, etc during this time. I set up a LOT of these people's IP networks, server rooms, built a lot of their first web applications, etc. This goes all the way back to things like the first discussion boards. In fact I may well have created THE first http based discussion board, hard coded handlers compiled directly into the CERN httpd that used BDB index files to implement multi-level threaded boards. It was all run under IRIX on big quad-core SGI servers. We had 128 megs of RAM in or main server that handled the NGA and some other organizations. I did buy a pile of Multias and got early RedHat working on them, mainly because BSD wasn't available for the Alpha processor they had in them. In any case, the point is BSD was at least as much used in the early server rooms as Linux was.
One of the real issues with Linux on a workstation in those days was A) there were no good graphics cards for PCs that could compete with the stuff on the workstations (and no drivers so you could run Linux on the DEC/SGI hardware) and CDE wasn't available on Linux. CDE was no prize but TWM was far more limited back then and it was mostly the only alternative. These days you can make a realistic Linux Workstation, but back then all the high performance hardware was proprietary and even the fastest 486s weren't in the same league with workstation processors, so I am not even really sure what you would have called a "Linux Workstation" back then. Believe me, had it been possible for there to be one I'd have been running it. My company had VERY good access to advanced hardware and software at that time and we played around with and used Linux a lot, but for real workstations it was SGIs or some of the Alpha based boxes, at least until around '98 when some of the Pentium II Xeon's started to show up with enough oomph to do the job.
There's NOTHING wrong with script files. As I've said elsewhere in this thread you are failing to understand good overall system design and factoring if you think a large complex program that incorporates every behavior into itself and puts only configuration options into files is 'superior'. A better solution would be individual scripts which can perform all the functions required for each service and coordinate with each other, with all the commonalities between them pulled out into shared library code. This allows for any level of flexibility and initialization strategy a packager or developer requires without forcing anyone to do anything and avoiding large disruptive changes in key subsystems.
I am really not interested in whether or not you understand the Unix way of doing things, but it is a real and highly beneficial approach which you might do well to actually understand. I don't have a big issue with a lot of the functionality that we're talking about here, though I think you are very much oversold on binary logging, but it doesn't all need to be bundled together in one package that is in any practical sense impossible to incorporate what you want from without being forced to swallow the whole thing.
And no, I'm not really being given a choice when the only option I have is something like Arch Linux, which no offense to its maintainers, is not something I'm going to run my bank on top of. Neither am I going to suddenly convert said operation to using systemd willingly. I've already had to deal with a lot of fallout from this stupid idea. I didn't have any problems before that needed this solution frankly and the changes ARE disruptive while we've noted zero practical benefit.
It wasn't Linux that killed DEC, I was there and saw it. By 1994 DEC was toast and that was purely because you could spend $5k on an x86 box that could do as much as your $50k DEC Alpha 4000 series. It was mostly stuff like Tandem and commercial unix running on x86 boxes that ate into their business, not Linux, which was NOTHING at the time. Recall the products DEC rolled out to try to fight it, there was Alpha itself, then there was the Multia, and there were several other workstation products, none of which could compete with NT on a Compaq.
Linux was a little sprout hiding in a bush watching the giants kill each other back then. It sure had nothing to do with the workstation market, though around 94 it started to become modestly popular as a quick cheap 'put it on some old 386s' server for mail/bind/etc and some casual web server stuff. FreeBSD was actually both a better choice and more popular in all those roles at the time. The only reason Linux thrived was the community was open and easy to play with, so it grew large quickly. The BSDs were a lot more elitist, you weren't WORTHY to commit code there. Anyway, I don't think systemd is going to sit well with the community, ever.
You have the factoring wrong on this sort of system design. You shouldn't have a monolithic controller implementing all these features. Instead you should have individual scripts that CAN do it any way they want, and then a large library of tools that properly implement all the things that people ACTUALLY want to do in a proper fashion. This allows incremental adoption, avoids dependency lock-in, and preserves flexibility and modularity. Instead of replacing init and trying to incorporate every possible feature in systemd and exposing them with configuration options what systemd SHOULD be is a set of functions that daemons can call and some wrappers that will let you compensate for or enhance whatever ill-behaving services already exist which can't simply be fixed up with changes to their init scripts.
As for security, that's an independent cross-cutting concern which is already handled by other tools. If there's a need for some command-line tools to expose some kernel functionality, or some libraries to do so, then that's one thing, but why is this grafted into the same tool that performs system startup? That's not good factoring.
We could have the same discussion WRT container support and other elements of systemd, most of which belong in completely seperate tools. If there needs to be additional framework around those different tools so they can do some new/better things then that should be done in the wider community so that we can have standards, not dumped on everyone as a fait acompli.
This is forced on me when I don't need or want it for exactly what reason that you can explain? If I want binary logging there are already solutions, which you have JUST NAMED which work fine. I've no need or interest in having an init system that is too big for its britches foisting another one on me. Compartmentalization IS important.
I have all sorts of high reliability services running on quite a few different servers, and I have plenty of them that will restart themselves, monitor their own crashrate and terminate completely if they crash N times in M minutes, etc. This is not rocket science and doesn't require to be built into PID 1 or something like that.
Frankly I think its a bad idea to create dependency chains onto huge complicated subsystems that often aren't appropriate, aren't needed, or are simply overkill.
Yeah, that could be better for some people. The $30 part is nice if you aren't going to use a HUGE amount of data and just want 4G. T-Mobile's network only has patchy 4G around here though, so I've not tried it. Truthfully all wireless internet kinda sucks in one way or another. At least some of the resellers are FAIRLY honest about what you get, like Straight Talk, and the price is pretty reasonable considering its an unlimited everything plan. At least you never need to be watching your usage.
Yeah, this is basically the best there is. Its mostly 3G speeds, but not always, and you will at least get what you get, all the time, at the best price there is. Frankly anyone expecting 4G speeds, unlimited, for less than huge money is just SOL.
But all of this AI nonsense is silly. Why would an AI be 'powerful'? First of all it is hard to imagine that any early generation AI will even be close to human in its capabilities, that would require mind-boggling amounts of computational power. Secondly we aren't even close to understanding how to make an efficient sort of AI and even further from making a complete one. What we're likely to produce is something pathetic by human standards, though clearly to be useful it will be very good at some specific thing(s). Beyond that why would an AI be dangerous? It will be a box or a facility somewhere. How will it actually accomplish anything except through us? And why would we be morons enough to make it otherwise? All the silly fantasies aside computers actually have relatively little direct control over anything. Nor do stupid fantasies like "the program escaped" ala 'Person of Interest' or some such bulldung have any relationship to reality. An AI will be something to pity at best, if it is even possible to pity it. 100 or 1000 years from now? Who knows, but today mankind is still a vastly greater threat to mankind than any machine is or can be in the foreseeable future.
Maybe. I think its actually pretty easy to do in one or another of the PA-supplied UIs, but I have yet to find clear instructions and mostly I just dread the "Oh, gosh, you touched a config file, that was a bad idea, how about not ever having sound again?" lol.
Yeah, I'm still trying to figure out how to record a Skype call. I'm sure its perfectly straightforward for any of the PA developers. I just haven't even been able to wrap my head around their terminology and concepts.
I think the PA gui control programs are the biggest issue, Pavucontrol and the other tools are just utterly confusing and obtuse. Typical developer designed UI paradigm, make a widget for each configuration parameter instead of thinking through the use cases and constructing some abstractions that make sense to the user and not the developer. Once the configuration is properly presented and a task-oriented UI is constructed around that I don't think PA will give people so many issues. There are a lot of neat things you CAN do with it, IF you can figure out how. Its just that no mortal human (myself included) can make heads nor tails of the frikking thing.
I have to agree, and I am a principle in a small software OEM, we deal with these issues all the time. Every one of our customers can see our buglists. Heck they can submit a ticket if they wish, and feature lists should be GOLD to the sales force.
Great, thanks! I am definitely getting some good info. 10 or 15 years ago when I was doing a lot of oddball stuff I'd have probably had one of these things ASAP. These days its hard to find the space and time to do projects, so I really am behind the curve. I have some interesting ideas, but nothing so solid that it yet warrants running out to spend $1000 (ouch) right now. At least I'm getting a better idea of what might be useful. Hopefully I can find a maker space that isn't too far away one of these days and try a few things out.
Slashdot Mirror
Ah, yeah, I've been reading around and I have to agree, the 40k must be a typo or something. So it sounds like these kinds of passes are something like 1/megayear. That doesn't make them exactly very likely to let you spread your civilization all that much, does it? I mean if you have a planning horizon of millions of years and have been around that long I'd expect a trip of 3-5 light years wouldn't be completely infeasible.
Exactly. Something like a fusion reaction energizing a VASIMIR-like magnetic nozzle choked down to a small diameter would produce a very high specific impulse (IE very fast exhaust velocity). You might also utilize gravity assist, but that would only be worth a fairly small increment of extra velocity (perhaps a Solar gravity assist would work, stealing some energy from the Sun's orbit around the galaxy, this could be possible though I don't know if it would be a good idea or not).
As far as the Voyager comment goes, they are going as fast as we could possibly get something moving at the time given the tech and navigational constraints. Its possible to attain somewhat higher velocities, but not a LOT higher with chemical rockets. Fusion power in the sense of a really efficient controlled fusion power source is not 'Star Trek' tech however. Its maybe 100 years out tech, but nothing new is required in terms of physics, etc. A fission rocket could actually work too, something like the Daedalus pusher-plate bomb concept could essentially be built today. It would be less efficient than some sort of advanced gas-core reactor, but we have not yet worked out how to build those either (easier than fusion probably, but not by a lot).
I feel confident that some pathway exists to say 100 AU/year velocities, which is enough for Oort Cloud type exploration, beyond that it is all very speculative though. There are plenty of concepts that can get to 8,000 AU, laser sails, fission/fusion, etc.
HIP 85605 will come within 8,000 AU of the Sun, still quite a distance, but VASTLY less than 3 light years. The blurb was also incorrect, this close pass will be in about 40k years, not 250k or more as stated (though perhaps this is a difference in sources, I don't know). 8,000 AU is something we could probably bridge with some advanced tech. For scale Voyager 1 is now at approximately 200 AU after 36 years of travel time, meaning it will take just shy of 2,000 years to reach this distance. It is certainly feasible to build a larger craft and fly it at 50x this speed using say fusion power, still only a very tiny fraction of C but yielding a trip time on the scale of a human lifetime. A little beyond our current engineering, but something similar to Daedelus, for instance, would suffice.
So, the idea isn't crazy. Its not that big a stretch of the imagination to think that true interstellar travel in the classic sense is simply infeasible. In fact it really is fairly difficult to imagine from an engineering perspective, there are technical issues so vast that they may well be insoluble, or only solvable by making compromises that are just not acceptable or limit such travel to very infrequent probes or something. That would leave close approaches as the single exception.
function pickPizza {
return { crust -> chewy, toppings -> [ 'pepperoni', 'extra cheese']};
}
Hey, ALL 60's cars were deathtraps! The OP never said anything about it had to be safe. Not sure why you hate on the '66 though, its a very classic model. The disc brakes were pretty much crap, but you can easily fix that (and by now if you own such a car it has long since been dealt with). The drive train in the performance model is pretty much standard Ford. The Windsor HiPO with the 4 barrel is a pretty nice engine.
Remember to get the high performance model, not the crappy one!
Oh, you didn't mean "drop in a new tranny when you said 'hack'??" Damned lazy kids.
Its just introducing another dependency. While I agree that shell scripts aren't the most elegant thing in existence and you could certainly write better ones in say Perl that would just mean that everyone would have to install an interpreter, just to boot their machine, and I think that wouldn't go over too well. Shells are unavoidable, so that dependency is pretty trivial.
Beyond that you can certainly write some perfectly nice shell scripts, and it should be possible to hide whatever ugliness there is with some more extensive libraries. Shell scripts allow for includes of packages of routines, and RedHat did a lot of work in that direction way back when. I guess they just had better things to do and it was never pushed to its limits. As I said before there are also /etc/sysinit scripts which are intended to contain ALL the user-settable configuration parameters for system services. Again, this hasn't been pushed hard, probably because its just not glamorous work.
Frankly I think if someone put their mind to it they could clean up the existing sysVinit process, init itself, build some libraries and establish some better conventions and you'd have 75% of the benefits of systemd without all the ruckus. The other 25% most people can probably live without and its not at all clear to me it belongs in the same project. Much of it could exist as stand-alone tools/libraries and some better conventions covering how to use cgroups and etc. That would IMHO have been a better approach.
There's NOTHING wrong with script files.
Using script files to setup and manage daemons because init is so primitive like SysVinit is, is simply a bad idea.
I'm sorry, but just saying "X is 'primitive'" isn't actually very useful. There is nothing primitive about scripts.
Also this isn't about SysVinit, this is about systemd. Picking at the one isn't an argument for the other. In fact SysVinit is pretty sophisticated in its own way, but its fine if we make it better or replace it with something BETTER. Again, just pointing out the problems with it isn't automatically enough to make systemd the correct alternative. I've pointed out negatives about the systemd approach, you need to address those.
Mixing executable code and declarative config statements like script based init systems do, is simply indefensible; it makes it hard to parse for both humans and machines.
There are two problems with this statement. First of all properly written init scripts ala RedHat put all their config in /etc/sysconfig, not mixed into any script. This is a perfectly easy practice that has been the state of the art for at least 10 years. Secondly blanket statements decreeing what is and isn't 'indefensible' are ridiculous. You need to make concrete arguments, I and many others are FAR past the point where any sort of decrees like this mean squat to us. There are many cases where basic invariant configuration elements are perfectly reasonably placed within a script. These are things that are not going to be changed in your installation but should be parameterized as good PROGRAMMING practice. Don't confuse those with configuration options that the system's user is going to want to change, they are very different things.
No one would ever design an init-system these days that didn't use pure text files for daemon config. SysVinit and similar are relics from a time when computing was done in a completely different way than today.
I am not trying to be disrespectful here for the pioneers that made various OS's back in the 1960's, 1970's and 1980's. It is just that some of the design choices they made, reflected the contemporary problems they had.
They made some simple but very flexible init systems based on shell scripts. But the simplicity just showed all kinds of problems over to the user space developer side, like handling dropping privileges when a daemon needed a low number port etc. And many people, including me, have long been of the opinion that such init-systems have been obsolete for years (if not decades). Most if not all certified Unix vendors have replaced their script based init systems (SMF and launchd are major inspiration init systems for systemd).
Horse Petunias. Computing hasn't fundamentally changed, and the same use cases that existed back in the mid 1980's when init systems in use today were birthed exist today. Believe me, I was there, and I know. A machine room today is solving the same problems that they were back then. Some of the technology is different and there are obviously some new things, but my 1980's Sun Unix machines ran pretty much like my Linux servers do today. If you want to tell me that a mobile phone is quite different from a mini-computer, well yes. However nobody is asserting that a mobile phone should be running the same init system as a web server, except the people making everything depend on systemd....
As I've said elsewhere in this thread you are failing to understand good overall system design and factoring if you think a large complex program that incorporates every behavior into itself and puts only configuration options into files is 'superior'.
I do think I understand enough about how OS's work to have a qualified opinion. We just happen to disagree about some things and is having a civilized exchange of arguments.
The core of systemd is certai
I don't know what 'SCO' has to do with it. Tandem wasn't SCO, they were supplying their own NonStop solution into the financial industry, which drove DEC's VAX cluster solutions clean out of that space. They were acquired by HP in 1997. I know because I was and still am friends with a number of the DEC engineers who worked in their clustering group in the late 80's and early 90's.
Linux had nothing in the way of traction in the workstation market in the 90's, it was not a player at all in any commercial sense. There was a very limited use of Linux on Multias by DEC as a way to make a cheap XTerm out of a failed workstation product, that was about it. Workstations at that time were heavily dominated by SGI with IBM, DEC, SUN, and some smaller 3rd party Alpha and MIPS system resellers. Many of those were NT 4.0 based boxes. I know people who used these things, sometimes 1000's of them, none of them ran Linux on them, it was unheard of. They were almost entirely used to run specific commercial applications (CAD, 3D software like Lightwave 3D, etc) which were rarely, if ever, ported to Linux (for instance there were some custom ports of Adobe products, which certainly shops had access to around this time, but they were never made widely available even to Adobe's bigger clients).
BSDs were indeed quite popular in the hosting space in the early-mid 90's. Linux eventually eclipsed BSD in most shops by around '97, but particularly in the 93-94 time frame there were significant issues with using Linux in Line-of-business server applications. I should know, I was a significant supplier to and engineer of commercial web solutions, local ISPs, etc during this time. I set up a LOT of these people's IP networks, server rooms, built a lot of their first web applications, etc. This goes all the way back to things like the first discussion boards. In fact I may well have created THE first http based discussion board, hard coded handlers compiled directly into the CERN httpd that used BDB index files to implement multi-level threaded boards. It was all run under IRIX on big quad-core SGI servers. We had 128 megs of RAM in or main server that handled the NGA and some other organizations. I did buy a pile of Multias and got early RedHat working on them, mainly because BSD wasn't available for the Alpha processor they had in them. In any case, the point is BSD was at least as much used in the early server rooms as Linux was.
One of the real issues with Linux on a workstation in those days was A) there were no good graphics cards for PCs that could compete with the stuff on the workstations (and no drivers so you could run Linux on the DEC/SGI hardware) and CDE wasn't available on Linux. CDE was no prize but TWM was far more limited back then and it was mostly the only alternative. These days you can make a realistic Linux Workstation, but back then all the high performance hardware was proprietary and even the fastest 486s weren't in the same league with workstation processors, so I am not even really sure what you would have called a "Linux Workstation" back then. Believe me, had it been possible for there to be one I'd have been running it. My company had VERY good access to advanced hardware and software at that time and we played around with and used Linux a lot, but for real workstations it was SGIs or some of the Alpha based boxes, at least until around '98 when some of the Pentium II Xeon's started to show up with enough oomph to do the job.
There's NOTHING wrong with script files. As I've said elsewhere in this thread you are failing to understand good overall system design and factoring if you think a large complex program that incorporates every behavior into itself and puts only configuration options into files is 'superior'. A better solution would be individual scripts which can perform all the functions required for each service and coordinate with each other, with all the commonalities between them pulled out into shared library code. This allows for any level of flexibility and initialization strategy a packager or developer requires without forcing anyone to do anything and avoiding large disruptive changes in key subsystems.
I am really not interested in whether or not you understand the Unix way of doing things, but it is a real and highly beneficial approach which you might do well to actually understand. I don't have a big issue with a lot of the functionality that we're talking about here, though I think you are very much oversold on binary logging, but it doesn't all need to be bundled together in one package that is in any practical sense impossible to incorporate what you want from without being forced to swallow the whole thing.
And no, I'm not really being given a choice when the only option I have is something like Arch Linux, which no offense to its maintainers, is not something I'm going to run my bank on top of. Neither am I going to suddenly convert said operation to using systemd willingly. I've already had to deal with a lot of fallout from this stupid idea. I didn't have any problems before that needed this solution frankly and the changes ARE disruptive while we've noted zero practical benefit.
It wasn't Linux that killed DEC, I was there and saw it. By 1994 DEC was toast and that was purely because you could spend $5k on an x86 box that could do as much as your $50k DEC Alpha 4000 series. It was mostly stuff like Tandem and commercial unix running on x86 boxes that ate into their business, not Linux, which was NOTHING at the time. Recall the products DEC rolled out to try to fight it, there was Alpha itself, then there was the Multia, and there were several other workstation products, none of which could compete with NT on a Compaq.
Linux was a little sprout hiding in a bush watching the giants kill each other back then. It sure had nothing to do with the workstation market, though around 94 it started to become modestly popular as a quick cheap 'put it on some old 386s' server for mail/bind/etc and some casual web server stuff. FreeBSD was actually both a better choice and more popular in all those roles at the time. The only reason Linux thrived was the community was open and easy to play with, so it grew large quickly. The BSDs were a lot more elitist, you weren't WORTHY to commit code there. Anyway, I don't think systemd is going to sit well with the community, ever.
You have the factoring wrong on this sort of system design. You shouldn't have a monolithic controller implementing all these features. Instead you should have individual scripts that CAN do it any way they want, and then a large library of tools that properly implement all the things that people ACTUALLY want to do in a proper fashion. This allows incremental adoption, avoids dependency lock-in, and preserves flexibility and modularity. Instead of replacing init and trying to incorporate every possible feature in systemd and exposing them with configuration options what systemd SHOULD be is a set of functions that daemons can call and some wrappers that will let you compensate for or enhance whatever ill-behaving services already exist which can't simply be fixed up with changes to their init scripts.
As for security, that's an independent cross-cutting concern which is already handled by other tools. If there's a need for some command-line tools to expose some kernel functionality, or some libraries to do so, then that's one thing, but why is this grafted into the same tool that performs system startup? That's not good factoring.
We could have the same discussion WRT container support and other elements of systemd, most of which belong in completely seperate tools. If there needs to be additional framework around those different tools so they can do some new/better things then that should be done in the wider community so that we can have standards, not dumped on everyone as a fait acompli.
this is precisely the point. There's no need for a single giant monolithic product that tries to do every damned thing.
This is forced on me when I don't need or want it for exactly what reason that you can explain? If I want binary logging there are already solutions, which you have JUST NAMED which work fine. I've no need or interest in having an init system that is too big for its britches foisting another one on me. Compartmentalization IS important.
I have all sorts of high reliability services running on quite a few different servers, and I have plenty of them that will restart themselves, monitor their own crashrate and terminate completely if they crash N times in M minutes, etc. This is not rocket science and doesn't require to be built into PID 1 or something like that.
Frankly I think its a bad idea to create dependency chains onto huge complicated subsystems that often aren't appropriate, aren't needed, or are simply overkill.
Yeah, that could be better for some people. The $30 part is nice if you aren't going to use a HUGE amount of data and just want 4G. T-Mobile's network only has patchy 4G around here though, so I've not tried it. Truthfully all wireless internet kinda sucks in one way or another. At least some of the resellers are FAIRLY honest about what you get, like Straight Talk, and the price is pretty reasonable considering its an unlimited everything plan. At least you never need to be watching your usage.
Yeah, this is basically the best there is. Its mostly 3G speeds, but not always, and you will at least get what you get, all the time, at the best price there is. Frankly anyone expecting 4G speeds, unlimited, for less than huge money is just SOL.
OK, in 140 years when you've made actual progress towards general-purpose AI and convinced me that one CAN EVEN BE WRITTEN by humans well....
But all of this AI nonsense is silly. Why would an AI be 'powerful'? First of all it is hard to imagine that any early generation AI will even be close to human in its capabilities, that would require mind-boggling amounts of computational power. Secondly we aren't even close to understanding how to make an efficient sort of AI and even further from making a complete one. What we're likely to produce is something pathetic by human standards, though clearly to be useful it will be very good at some specific thing(s). Beyond that why would an AI be dangerous? It will be a box or a facility somewhere. How will it actually accomplish anything except through us? And why would we be morons enough to make it otherwise? All the silly fantasies aside computers actually have relatively little direct control over anything. Nor do stupid fantasies like "the program escaped" ala 'Person of Interest' or some such bulldung have any relationship to reality. An AI will be something to pity at best, if it is even possible to pity it. 100 or 1000 years from now? Who knows, but today mankind is still a vastly greater threat to mankind than any machine is or can be in the foreseeable future.
Maybe. I think its actually pretty easy to do in one or another of the PA-supplied UIs, but I have yet to find clear instructions and mostly I just dread the "Oh, gosh, you touched a config file, that was a bad idea, how about not ever having sound again?" lol.
Yeah, I'm still trying to figure out how to record a Skype call. I'm sure its perfectly straightforward for any of the PA developers. I just haven't even been able to wrap my head around their terminology and concepts.
I think the PA gui control programs are the biggest issue, Pavucontrol and the other tools are just utterly confusing and obtuse. Typical developer designed UI paradigm, make a widget for each configuration parameter instead of thinking through the use cases and constructing some abstractions that make sense to the user and not the developer. Once the configuration is properly presented and a task-oriented UI is constructed around that I don't think PA will give people so many issues. There are a lot of neat things you CAN do with it, IF you can figure out how. Its just that no mortal human (myself included) can make heads nor tails of the frikking thing.
Mars One is HUGELY optimistic. Optimism is great as a general life trait, but its a terrible way to design things.
I have to agree, and I am a principle in a small software OEM, we deal with these issues all the time. Every one of our customers can see our buglists. Heck they can submit a ticket if they wish, and feature lists should be GOLD to the sales force.
Great, thanks! I am definitely getting some good info. 10 or 15 years ago when I was doing a lot of oddball stuff I'd have probably had one of these things ASAP. These days its hard to find the space and time to do projects, so I really am behind the curve. I have some interesting ideas, but nothing so solid that it yet warrants running out to spend $1000 (ouch) right now. At least I'm getting a better idea of what might be useful. Hopefully I can find a maker space that isn't too far away one of these days and try a few things out.