That is about where I am with Android Wear. All things being equal I'd love to have a watch that can use NTP, display notifications, and do Google Now (the "equivalent" of Siri). However, it costs WAY more than a watch and needs daily recharging. I just don't get enough notifications when I'm not already staring at a phone/PC to benefit from this.
Maybe the killer app will emerge, maybe it will cost $30 some day, or maybe my needs will change. At that point I might own one.
Its main advantage is that you don't need anybody's permission to use it.
Considering it's even banned in some countries, it's even illegal to use in some places. No permission necessary to break the law.
Sure, but the point is that no central body needs to endorse every user/transaction/etc. With something like a credit card you need to be blessed by a central authority before you can take part in a transaction from either side. In that regard it is like cash. It is illegal to do cash transactions in some circumstances in many countries, but to use cash you just have to have possession of it in practice.
Yeah, but who uses Gmail, or Google Maps, or Google Now anyway?
Oh, that's right - probably 99% of Android users. I'll buy that Gmail is a bit less ubiquitous, but the other two are practically platform-defining. My wife can't stand the idea of owning a smartphone but even she gets envious when she hears my phone give lane advisories during navigation.
The point of bitcoin is to be a CURRENCY, not an investment. Sure, people invest in currencies all the time, but I don't have cash in my wallet in the hope that the dollar will go up relative to the euro, etc. I have it in my wallet so that I can buy $5 worth of food at a store without using a credit card.
Its main advantage is that you don't need anybody's permission to use it.
Suppose I have a hat and want to sell it to you for $20 (maybe on a site like Ebay). How do you give me $20? You can mail me a check, which takes days, or you can pay by credit card fairly instantly but I need a merchant account to accept the payment. Or, we can use something like Paypal, which might decide to just take either of our money during the time they hold it. With Bitcoin you can put $20 in your wallet which nobody else has access to, and send it to my account, which nobody but I have access to. Both of us can agree that the money changed hands, and then I can ship you the goods.
Now, Bitcoin is equivalent to cash in the sense that if I don't ship you the goods, you're up the creek.
I'd love it if Paypal acted as a broker to let a buyer pay by credit card and for me to receive payment instantly by Bitcoin. In this mode of operation I'd get my payment instantly, and I don't have to worry about Paypal deciding to seize my funds (which they have a bit of a reputation for). I doubt it will ever happen, however.
The bottom line is that if people want FOSS to go in a particular direction, they have to fork out money or code. Talk is cheap, and fairly ineffective. That is true whether you're talking about commercial or volunteer-based projects.
The point is that it have been relatively easy to fork off eudev and keep up with udev, but that will change with kdbus integration. Not only will the forked code differ quite a lot, but the way user space programs will use udev will also change. This will take some serious developer time to counter, one way or another.
Maybe, but I suspect that eudev will just merge in the changes wholesale, which doesn't require a great deal of effort. I don't think there is any driver to keep kdbus support out of eudev.
In some ways the sweeping systemd victory, is a replay of the PulseAudio distro victory.
Sure, but believe it or not I don't have pulseaudio installed on my system. I don't really have any objections to it - I just haven't had any need for it either and thus haven't gotten around to installing it (even though that probably would only take 15min). If some program I used needed it I'd get it working.
They can barely maintain basic forks of udev, so when udev gets kdbus support, forks like "eudev" will begin to really differ from "udev".
While there was a lot of the usual flames at the time of formation of eudev, from what I've seen in practice the folks maintaining it actually do try to follow udev reasonably closely and they certainly talk to their udev/systemd counterparts within Gentoo. There are certainly some philisophical differences, but I suspect that when kdbus comes along the eudev folks may embrace it (it is, after all, going to be part of the kernel). I think there is recognition that if they try to go in a completely different direction they're going to be short on manpower to keep it useful. The main maintainers of OpenRC on Gentoo are also involved in maintaining systemd.
I'm closer to Gentoo than anything else, but from the occasional debian mailing list browsing I get the sense that the winds are blowing the same for both distros. There are people who aren't happy about systemd in both places, but nobody really wants to create yet another distro from the ground up to try to avoid it. There is a tendency to cheerlead anything that looks like opposition, but the fact is that most of the people actually doing the work have a grasp on the momentum systemd has.
Gentoo is a bit of a niche distro and has always been about fostering choices, so stuff like openrc/eudev, or even using busybox to populate/dev are going to tend to be supported to some extent for a long time. Gentoo also supports BSD, so OpenRC will be mainstream there indefinitely. I suspect that it won't be too long until the majority of users have switched to systemd.
By the extension of that first thought, it means you can turn a distro into either desktop or server versions by removing the pieces that do one thing well and adding others.
I mostly agree, but there have been some radical departures. You have stuff like android/chromeos which are huge departures from the typical linux server. You also have stuff like CoreOS which is a huge departure from tradition and which wouldn't work very well as the basis of a desktop distro (unless you're talking about serving virtual desktops - which obviously has a blend of server/desktop-like needs).
The few non-systemd distros left haven't even begun to cooperate. So it looks unlikely right now that any non-systemd distros of note will survive into the next decade.
What non-systemd distros are even out there? I hear slackware doesn't support systemd. Does anybody else not support it (well, of any of the significant distros)?
People bring up Gentoo as a non-systemd distro, but at this point systemd works about as well on Gentoo as it does on just about any distro, and about as well as sysvinit on Gentoo. It just doesn't come pre-installed (but my guess is that within a year neither will sysvinit - the Gentoo way in these cases tends to be to let the user make their choice and install what they want - Gentoo doesn't come with a kernel, grub, syslog, or cron preinstalled either, or even a sendmail implementation (including the really light ones)).
As a side note, it's becoming increasingly frustrating to be a non-systemd user. I've had to re-arrange a tonne of packages as stuff switches. I know systemd is inevitable, but I'd like to hold out just a little longer:(
There is a reason it is popular.:) I'm sure OpenRC will be as supported as it can be on Gentoo for a long time, but we can't control what upstream does (Gnome, etc).
At this point SystemD on Gentoo is pretty mature, so you probably should at least experiment with it. I suspect that within a year sysvinit will no longer be in the stage3s and you'll just pick an init during install the way you pick a syslog or kernel or bootloader. It has gotten to the point where installing systemd from a stage3 is as simple as setting USE=systemd and doing an emerge -uDN world, and then configuring some of the system-level stuff like timezone/etc (which you'd do for openrc as well - since the systemd install does a migration of settings you could also configure those things the old way before installing systemd).
The one issue I've found with systemd is that it is MUCH more aggressive with parallel startup than openrc was (it is just faster), which tends to expose more dependency issues. It is mostly a problem if you run services like nfs, named, etc, since many of the daemons assume that those sorts of services are hosted elsewhere and thus aren't dependencies. It isn't too hard to fix these issues, but it is still immature.
You can build and install binary packages on Gentoo. That is actually the approach that most admins of Gentoo-based datacenters take. Granted, it isn't nearly as popular as Debian/CentOS for obvious reasons. However, there are niches where it is used, and a perfect one is when you have a need to be able to tweak compile-time configuration of many packages (like stripping out X11). Gentoo Hardened has been popular for a long time as well (though other distros have matured quite a bit in this space - Gentoo hardened has been around for a LONG time and became popular in places like some VPS hosts for this reason back before SELinux became more mainstream).
Gentoo is a bit of a meta-distro, so if you have a configuration you like you can pretty easily roll your own "distro" and keep it up to date. Just build/test updates on one box, and when they're ready publish repository changes and binary packages and have all your other servers automatically install them. By hosting your own private repository you have complete control over what goes out.
Yup. The first system I installed systemd on was a server. I was running a daemon which tended to crash, and systemd was very good at both restarting it when it crashed, and tidying up after children it might have left running. It also has lots of support for process namespaces or fairly complete containers, which are very server-ish features.
Sure, but even this is more sensible for a multi-user system. If I'm running a desktop I don't really care if I leave a process running when I walk away from it. On the other hand, if I were serving out remotely-accessed desktop sessions I'd certainly want the system to clean up after somebody logs off, or kill idle sessions.
Splitting upstream would be disastrous. (Desktop would lose the behemoth of code contributions from Redhat for the most part).
Just leave it to the distro's to do the 'splitting'.
EG Ubuntu Server vs Desktop
Yup. The fact is that virtually all the investment in Linux is for running it as a server. That is where the money is.
The desktop stuff just layers some applications on top, benefiting from the stable platform underneath. The more the desktop diverges, the less support it is going to tend to get, since nobody really invests in linux for the desktop seriously.
I would agree that it is much more complex, and therefore much more vulnerable to bugs, but that is the price of actually having an init that does things.
If you like buggy, monolithic services, why don't you just run a Windows server instead of infecting Linux. I am getting more and more the feeling that systemd is being pushed to kill of Linux.
What is monolithic about systemd? It is a grouping of programs that can be run together or in isolation, with each one doing one thing well. In the case of systemd itself it executes processes and supervises them, which is more-or-less what init does via inittab except that systemd gives you a lot more control over how processes are run, is far easier to control/configure, and cleans up after itself.
And nobody is infecting your linux. Don't install systemd on your machine, and it will work exactly the way it does today, forever. I'm sure whoever you're paying to keep your system up-to-date can keep it working without installing systemd.
What daemon manager solves those problems? And what is the point of having an init that basically does nothing but spawn a daemon manager and a few gettys? Why not just move that code into the kernel (oh wait, it is already there - it launches init)?
If your daemon manager really did do all the stuff you want it to do, and it dies, then the effects would be about the same as init crashing anyway.
Indeed. When, pray tell, was the last time init crashed on you? 28yrs of unix sysadmin, I can't recall one.
It never has crashed for me. What is your point?
The argument was that init isn't supposed to be a daemon manager, since there are other daemon managers out there. I pointed out that those have problems too, and isolating that code from init doesn't really bring any benefits. If init dies your webserver goes down. If the daemon manager crashes and kills your webserver, your webserver goes down, but init will happily continue to run and do nothing like it usually does, except maybe wait for any exit codes so that the crashed processes don't become zombies.
And, I've yet to see systemd crash either, but as I already said I'm more than willing to agree that this seems more likely than sysvinit crashing.
The simplicity of sysvinit basically limits its usefulness, and once you start talking about using other processes to make up for its shortcomings, you lose all the benefits of your simple sysvinit whether that other process runs as PID 1 or not.
The point is that they're API's. That is what makes systemd a fragile monolith. And the solution to this is to not allow anything to replace a part of systemd; if you want an alternative it will run in parallel with the systemd equivalent.
Just what systemd components can't be replaced? If you enable the dhcpcd service, it will happily configure your network just like it would in sysvinit, and you don't need to run networkd/resolved/etc.
About the only component that anybody is likely to run in parallel is journald, and if you set journald to non-persistant mode then you can view it as just a daemon that captures console output from daemons that would otherwise be lost, since it doesn't interfere with syslog at all.
My example was contrived. The point is that tor doesn't prevent you from leaking identifying info. There are LOTS of ways this can happen, including:
1. Some application happens to embed a non-private IP in the data stream (maybe in a header or something). This is a classic problem if you try to run bittorrent over tor. 2. Somebody manages to run arbitrary code on your server via an exploit and this code has access to identifying information, such as a non-private IP, mac address, or just the ability to send packets to the internet (which can be sent to a server controlled by the attacker revealing the source IP).
Neither of these requires NSA-like capabilities to pull off, or the ability to defeat tor in general.
Ah, in this case it is even easier to anonymize then, assuming you don't care about the buyers or the sellers. Just store all the data on the servers with nothing identifying, and the only thing you have to deal with is getting the listing fees off the site.
I'll confess I don't know a great deal about the Silk Road, as I've never visited the site.
It's not supposed to do that. It's an INIT system. If you want a daemon manager, the init system can start one for you.
What daemon manager solves those problems? And what is the point of having an init that basically does nothing but spawn a daemon manager and a few gettys? Why not just move that code into the kernel (oh wait, it is already there - it launches init)?
I spawn services from init. It works very well, on, off, once, respawn. It's very fast when it restarts a service and if a service flaps then it won't expend all of CPU restarting, it will just wait before attempting to restart the service and scream loudly in the meantime. I don't wonder if it is working because init is so responsive.
Perhaps it's just easy for people to write bad init.d scripts and everything 'kinda' works?
The problems with this approach are outlined in the post above. It isn't easy for you to stop that service, and init can't guarantee that it gets everything even if you do set up multiple runlevels and use telinit (and in this configuration you don't have per-daemon control either). There is nothing like cgroup support. You are correct that init will respawn things if they die - I've done this myself back in the day. You also lose all console output as well, unless you stick some kind of a wrapper around your service.
If your daemon manager really did do all the stuff you want it to do, and it dies, then the effects would be about the same as init crashing anyway.
I've tried to make init crash in tests - it's very difficult. As a daemon manager, init works well.
Sure, crashing init is very hard - it doesn't really do anything, and that is the whole point. Systemd is rather hard to crash as well. I would agree that it is much more complex, and therefore much more vulnerable to bugs, but that is the price of actually having an init that does things.
If you're happy with sysvinit, it isn't like the code is going to magically disappear. It hasn't changed in ages, and I'm sure it will still work on linux-4.5.0.
Oh, I wouldn't just worry about flash. I'd assume that somebody I don't like is going to find an exploit in my webserver, and run arbitrary code on that host, and every other host it can reach via the network. All of this stuff has to run in a DMZ that contains no identifying information at all. That is certainly a challenge to do in practice.
Well, in their case they are running a storefront. That has a few components. 1. You need a searchable catalog of stuff that you are selling, and the ability to put together orders. That isn't too sensitive up until you checkout since your goal is to advertise the catalog anyway.
2. You need to be able to collect info on where to ship the goods. This is sensitive information if you don't want people figuring out who your customers are. You can't avoid collecting this info from your customers, but you could control storage of it. The first time somebody sets up an account you could collect info from them, but then you could take that data off the network and just reference their account number inside the network. As long as the customer sticks with the same delivery address and doesn't care that the order doesn't show it, then their info could be safe from compromise a few days after their first order.
3. You need to handle payment. Since they traded in Bitcoin this also could be done in a way that doesn't eliminate the risk of problems, but it does greatly mitigate it. For each transaction create a bitcoin account, and the tor-connected network can provide those details to the client so that they can make payment. At that point you can remove that data from the tor-connected network and move it elsewhere. That means that if somebody gets onto the network they can only get your bitcoin credentials for a few days worth of transactions, and future transactions going forward. Money would be moved out of those accounts into another set of accounts whose credentials were never at risk as soon as it was received, so if there were an attempt to seize funds it would be limited to accounts that only received funds recently.
All the order fulfilment can happen off of the tor-connected network. Getting data between the networks could involve sneakernet, or maybe even manual printing of paper orders. An operation like Silk Road is no doubt very high-margin, and I can't imagine that they can operate at high volume without risk of detection. So, a manual process where tor tells you ship 2kg of product A to customer 123 just means punching 2, A, and 123 into another application which prints out the shipping label - that system doesn't need to be attached to the internet. Dealing with bitcoin account numbers and credentials might be more of a pain, since they are long numbers.
"Better for the herd? Yup." If we have higher pneumonia rates, then no it s NOT better for the herd.
That depends greatly on whether the increase in pneumonia is offset by decreases in other problems like MRSA (especially considering that the former is much more treatable).
That is one of the problems we have in healthcare - sometimes the best decision isn't the best decision for every individual, but if we want to really improve average health we need to still make the hard choices. If I'm the guy who stands a 2% chance of recovering if somebody spends $200k on cancer therapy, then that may very well be the right decision from my standpoint. On the other hand, the poor kid who needs a heart transplant that has a 90% likelihood of a long and happy life and can't afford one might feel differently about where that $200k should go.
Stick a php_info in your code or something equivalent. I don't believe the FBI was claiming that they received traffic from a non-tor IP, but rather that they received an IP address somewhere in the data sent over tor.
Nothing in tor prevents you from sending your name, address, and social security number in the html of a webpage that you serve. If I wanted to depend on a website remaining anonymous over tor I'd probably stick the entire thing on a private network (with private IPs) such that none of the machines ever contained identifying information (including traceable machine IDs or MACs/etc), heavily firewall it, and carefully control that nothing goes out except via tor. I'd treat every device on the network as if it were compromised and intentionally trying to communicate out every bit of data stored within, so it would be essential that none of these devices contain any information worth stealing.
It's not supposed to do that. It's an INIT system. If you want a daemon manager, the init system can start one for you.
What daemon manager solves those problems? And what is the point of having an init that basically does nothing but spawn a daemon manager and a few gettys? Why not just move that code into the kernel (oh wait, it is already there - it launches init)?
If your daemon manager really did do all the stuff you want it to do, and it dies, then the effects would be about the same as init crashing anyway.
Slashdot Mirror
That is about where I am with Android Wear. All things being equal I'd love to have a watch that can use NTP, display notifications, and do Google Now (the "equivalent" of Siri). However, it costs WAY more than a watch and needs daily recharging. I just don't get enough notifications when I'm not already staring at a phone/PC to benefit from this.
Maybe the killer app will emerge, maybe it will cost $30 some day, or maybe my needs will change. At that point I might own one.
Considering it's even banned in some countries, it's even illegal to use in some places. No permission necessary to break the law.
Sure, but the point is that no central body needs to endorse every user/transaction/etc. With something like a credit card you need to be blessed by a central authority before you can take part in a transaction from either side. In that regard it is like cash. It is illegal to do cash transactions in some circumstances in many countries, but to use cash you just have to have possession of it in practice.
Yeah, but who uses Gmail, or Google Maps, or Google Now anyway?
Oh, that's right - probably 99% of Android users. I'll buy that Gmail is a bit less ubiquitous, but the other two are practically platform-defining. My wife can't stand the idea of owning a smartphone but even she gets envious when she hears my phone give lane advisories during navigation.
The point of bitcoin is to be a CURRENCY, not an investment. Sure, people invest in currencies all the time, but I don't have cash in my wallet in the hope that the dollar will go up relative to the euro, etc. I have it in my wallet so that I can buy $5 worth of food at a store without using a credit card.
Its main advantage is that you don't need anybody's permission to use it.
Suppose I have a hat and want to sell it to you for $20 (maybe on a site like Ebay). How do you give me $20? You can mail me a check, which takes days, or you can pay by credit card fairly instantly but I need a merchant account to accept the payment. Or, we can use something like Paypal, which might decide to just take either of our money during the time they hold it. With Bitcoin you can put $20 in your wallet which nobody else has access to, and send it to my account, which nobody but I have access to. Both of us can agree that the money changed hands, and then I can ship you the goods.
Now, Bitcoin is equivalent to cash in the sense that if I don't ship you the goods, you're up the creek.
I'd love it if Paypal acted as a broker to let a buyer pay by credit card and for me to receive payment instantly by Bitcoin. In this mode of operation I'd get my payment instantly, and I don't have to worry about Paypal deciding to seize my funds (which they have a bit of a reputation for). I doubt it will ever happen, however.
Agree.
The bottom line is that if people want FOSS to go in a particular direction, they have to fork out money or code. Talk is cheap, and fairly ineffective. That is true whether you're talking about commercial or volunteer-based projects.
The point is that it have been relatively easy to fork off eudev and keep up with udev, but that will change with kdbus integration. Not only will the forked code differ quite a lot, but the way user space programs will use udev will also change. This will take some serious developer time to counter, one way or another.
Maybe, but I suspect that eudev will just merge in the changes wholesale, which doesn't require a great deal of effort. I don't think there is any driver to keep kdbus support out of eudev.
In some ways the sweeping systemd victory, is a replay of the PulseAudio distro victory.
Sure, but believe it or not I don't have pulseaudio installed on my system. I don't really have any objections to it - I just haven't had any need for it either and thus haven't gotten around to installing it (even though that probably would only take 15min). If some program I used needed it I'd get it working.
They can barely maintain basic forks of udev, so when udev gets kdbus support, forks like "eudev" will begin to really differ from "udev".
While there was a lot of the usual flames at the time of formation of eudev, from what I've seen in practice the folks maintaining it actually do try to follow udev reasonably closely and they certainly talk to their udev/systemd counterparts within Gentoo. There are certainly some philisophical differences, but I suspect that when kdbus comes along the eudev folks may embrace it (it is, after all, going to be part of the kernel). I think there is recognition that if they try to go in a completely different direction they're going to be short on manpower to keep it useful. The main maintainers of OpenRC on Gentoo are also involved in maintaining systemd.
I'm closer to Gentoo than anything else, but from the occasional debian mailing list browsing I get the sense that the winds are blowing the same for both distros. There are people who aren't happy about systemd in both places, but nobody really wants to create yet another distro from the ground up to try to avoid it. There is a tendency to cheerlead anything that looks like opposition, but the fact is that most of the people actually doing the work have a grasp on the momentum systemd has.
Gentoo is a bit of a niche distro and has always been about fostering choices, so stuff like openrc/eudev, or even using busybox to populate /dev are going to tend to be supported to some extent for a long time. Gentoo also supports BSD, so OpenRC will be mainstream there indefinitely. I suspect that it won't be too long until the majority of users have switched to systemd.
By the extension of that first thought, it means you can turn a distro into either desktop or server versions by removing the pieces that do one thing well and adding others.
I mostly agree, but there have been some radical departures. You have stuff like android/chromeos which are huge departures from the typical linux server. You also have stuff like CoreOS which is a huge departure from tradition and which wouldn't work very well as the basis of a desktop distro (unless you're talking about serving virtual desktops - which obviously has a blend of server/desktop-like needs).
The few non-systemd distros left haven't even begun to cooperate. So it looks unlikely right now that any non-systemd distros of note will survive into the next decade.
What non-systemd distros are even out there? I hear slackware doesn't support systemd. Does anybody else not support it (well, of any of the significant distros)?
People bring up Gentoo as a non-systemd distro, but at this point systemd works about as well on Gentoo as it does on just about any distro, and about as well as sysvinit on Gentoo. It just doesn't come pre-installed (but my guess is that within a year neither will sysvinit - the Gentoo way in these cases tends to be to let the user make their choice and install what they want - Gentoo doesn't come with a kernel, grub, syslog, or cron preinstalled either, or even a sendmail implementation (including the really light ones)).
As a side note, it's becoming increasingly frustrating to be a non-systemd user. I've had to re-arrange a tonne of packages as stuff switches. I know systemd is inevitable, but I'd like to hold out just a little longer :(
There is a reason it is popular. :) I'm sure OpenRC will be as supported as it can be on Gentoo for a long time, but we can't control what upstream does (Gnome, etc).
At this point SystemD on Gentoo is pretty mature, so you probably should at least experiment with it. I suspect that within a year sysvinit will no longer be in the stage3s and you'll just pick an init during install the way you pick a syslog or kernel or bootloader. It has gotten to the point where installing systemd from a stage3 is as simple as setting USE=systemd and doing an emerge -uDN world, and then configuring some of the system-level stuff like timezone/etc (which you'd do for openrc as well - since the systemd install does a migration of settings you could also configure those things the old way before installing systemd).
The one issue I've found with systemd is that it is MUCH more aggressive with parallel startup than openrc was (it is just faster), which tends to expose more dependency issues. It is mostly a problem if you run services like nfs, named, etc, since many of the daemons assume that those sorts of services are hosted elsewhere and thus aren't dependencies. It isn't too hard to fix these issues, but it is still immature.
You can build and install binary packages on Gentoo. That is actually the approach that most admins of Gentoo-based datacenters take. Granted, it isn't nearly as popular as Debian/CentOS for obvious reasons. However, there are niches where it is used, and a perfect one is when you have a need to be able to tweak compile-time configuration of many packages (like stripping out X11). Gentoo Hardened has been popular for a long time as well (though other distros have matured quite a bit in this space - Gentoo hardened has been around for a LONG time and became popular in places like some VPS hosts for this reason back before SELinux became more mainstream).
Gentoo is a bit of a meta-distro, so if you have a configuration you like you can pretty easily roll your own "distro" and keep it up to date. Just build/test updates on one box, and when they're ready publish repository changes and binary packages and have all your other servers automatically install them. By hosting your own private repository you have complete control over what goes out.
Yup. The first system I installed systemd on was a server. I was running a daemon which tended to crash, and systemd was very good at both restarting it when it crashed, and tidying up after children it might have left running. It also has lots of support for process namespaces or fairly complete containers, which are very server-ish features.
Sure, but even this is more sensible for a multi-user system. If I'm running a desktop I don't really care if I leave a process running when I walk away from it. On the other hand, if I were serving out remotely-accessed desktop sessions I'd certainly want the system to clean up after somebody logs off, or kill idle sessions.
Splitting upstream would be disastrous. (Desktop would lose the behemoth of code contributions from Redhat for the most part).
Just leave it to the distro's to do the 'splitting'.
EG Ubuntu Server vs Desktop
Yup. The fact is that virtually all the investment in Linux is for running it as a server. That is where the money is.
The desktop stuff just layers some applications on top, benefiting from the stable platform underneath. The more the desktop diverges, the less support it is going to tend to get, since nobody really invests in linux for the desktop seriously.
I would agree that it is much more complex, and therefore much more vulnerable to bugs, but that is the price of actually having an init that does things.
If you like buggy, monolithic services, why don't you just run a Windows server instead of infecting Linux. I am getting more and more the feeling that systemd is being pushed to kill of Linux.
What is monolithic about systemd? It is a grouping of programs that can be run together or in isolation, with each one doing one thing well. In the case of systemd itself it executes processes and supervises them, which is more-or-less what init does via inittab except that systemd gives you a lot more control over how processes are run, is far easier to control/configure, and cleans up after itself.
And nobody is infecting your linux. Don't install systemd on your machine, and it will work exactly the way it does today, forever. I'm sure whoever you're paying to keep your system up-to-date can keep it working without installing systemd.
What daemon manager solves those problems? And what is the point of having an init that basically does nothing but spawn a daemon manager and a few gettys? Why not just move that code into the kernel (oh wait, it is already there - it launches init)?
If your daemon manager really did do all the stuff you want it to do, and it dies, then the effects would be about the same as init crashing anyway.
Indeed. When, pray tell, was the last time init crashed on you? 28yrs of unix sysadmin, I can't recall one.
It never has crashed for me. What is your point?
The argument was that init isn't supposed to be a daemon manager, since there are other daemon managers out there. I pointed out that those have problems too, and isolating that code from init doesn't really bring any benefits. If init dies your webserver goes down. If the daemon manager crashes and kills your webserver, your webserver goes down, but init will happily continue to run and do nothing like it usually does, except maybe wait for any exit codes so that the crashed processes don't become zombies.
And, I've yet to see systemd crash either, but as I already said I'm more than willing to agree that this seems more likely than sysvinit crashing.
The simplicity of sysvinit basically limits its usefulness, and once you start talking about using other processes to make up for its shortcomings, you lose all the benefits of your simple sysvinit whether that other process runs as PID 1 or not.
The point is that they're API's. That is what makes systemd a fragile monolith. And the solution to this is to not allow anything to replace a part of systemd; if you want an alternative it will run in parallel with the systemd equivalent.
Just what systemd components can't be replaced? If you enable the dhcpcd service, it will happily configure your network just like it would in sysvinit, and you don't need to run networkd/resolved/etc.
About the only component that anybody is likely to run in parallel is journald, and if you set journald to non-persistant mode then you can view it as just a daemon that captures console output from daemons that would otherwise be lost, since it doesn't interfere with syslog at all.
My example was contrived. The point is that tor doesn't prevent you from leaking identifying info. There are LOTS of ways this can happen, including:
1. Some application happens to embed a non-private IP in the data stream (maybe in a header or something). This is a classic problem if you try to run bittorrent over tor.
2. Somebody manages to run arbitrary code on your server via an exploit and this code has access to identifying information, such as a non-private IP, mac address, or just the ability to send packets to the internet (which can be sent to a server controlled by the attacker revealing the source IP).
Neither of these requires NSA-like capabilities to pull off, or the ability to defeat tor in general.
Ah, in this case it is even easier to anonymize then, assuming you don't care about the buyers or the sellers. Just store all the data on the servers with nothing identifying, and the only thing you have to deal with is getting the listing fees off the site.
I'll confess I don't know a great deal about the Silk Road, as I've never visited the site.
It's not supposed to do that. It's an INIT system. If you want a daemon manager, the init system can start one for you.
What daemon manager solves those problems? And what is the point of having an init that basically does nothing but spawn a daemon manager and a few gettys? Why not just move that code into the kernel (oh wait, it is already there - it launches init)?
I spawn services from init. It works very well, on, off, once, respawn. It's very fast when it restarts a service and if a service flaps then it won't expend all of CPU restarting, it will just wait before attempting to restart the service and scream loudly in the meantime. I don't wonder if it is working because init is so responsive.
Perhaps it's just easy for people to write bad init.d scripts and everything 'kinda' works?
The problems with this approach are outlined in the post above. It isn't easy for you to stop that service, and init can't guarantee that it gets everything even if you do set up multiple runlevels and use telinit (and in this configuration you don't have per-daemon control either). There is nothing like cgroup support. You are correct that init will respawn things if they die - I've done this myself back in the day. You also lose all console output as well, unless you stick some kind of a wrapper around your service.
If your daemon manager really did do all the stuff you want it to do, and it dies, then the effects would be about the same as init crashing anyway.
I've tried to make init crash in tests - it's very difficult. As a daemon manager, init works well.
Sure, crashing init is very hard - it doesn't really do anything, and that is the whole point. Systemd is rather hard to crash as well. I would agree that it is much more complex, and therefore much more vulnerable to bugs, but that is the price of actually having an init that does things.
If you're happy with sysvinit, it isn't like the code is going to magically disappear. It hasn't changed in ages, and I'm sure it will still work on linux-4.5.0.
Oh, I wouldn't just worry about flash. I'd assume that somebody I don't like is going to find an exploit in my webserver, and run arbitrary code on that host, and every other host it can reach via the network. All of this stuff has to run in a DMZ that contains no identifying information at all. That is certainly a challenge to do in practice.
Well, in their case they are running a storefront. That has a few components.
1. You need a searchable catalog of stuff that you are selling, and the ability to put together orders. That isn't too sensitive up until you checkout since your goal is to advertise the catalog anyway.
2. You need to be able to collect info on where to ship the goods. This is sensitive information if you don't want people figuring out who your customers are. You can't avoid collecting this info from your customers, but you could control storage of it. The first time somebody sets up an account you could collect info from them, but then you could take that data off the network and just reference their account number inside the network. As long as the customer sticks with the same delivery address and doesn't care that the order doesn't show it, then their info could be safe from compromise a few days after their first order.
3. You need to handle payment. Since they traded in Bitcoin this also could be done in a way that doesn't eliminate the risk of problems, but it does greatly mitigate it. For each transaction create a bitcoin account, and the tor-connected network can provide those details to the client so that they can make payment. At that point you can remove that data from the tor-connected network and move it elsewhere. That means that if somebody gets onto the network they can only get your bitcoin credentials for a few days worth of transactions, and future transactions going forward. Money would be moved out of those accounts into another set of accounts whose credentials were never at risk as soon as it was received, so if there were an attempt to seize funds it would be limited to accounts that only received funds recently.
All the order fulfilment can happen off of the tor-connected network. Getting data between the networks could involve sneakernet, or maybe even manual printing of paper orders. An operation like Silk Road is no doubt very high-margin, and I can't imagine that they can operate at high volume without risk of detection. So, a manual process where tor tells you ship 2kg of product A to customer 123 just means punching 2, A, and 123 into another application which prints out the shipping label - that system doesn't need to be attached to the internet. Dealing with bitcoin account numbers and credentials might be more of a pain, since they are long numbers.
"Better for the herd? Yup."
If we have higher pneumonia rates, then no it s NOT better for the herd.
That depends greatly on whether the increase in pneumonia is offset by decreases in other problems like MRSA (especially considering that the former is much more treatable).
That is one of the problems we have in healthcare - sometimes the best decision isn't the best decision for every individual, but if we want to really improve average health we need to still make the hard choices. If I'm the guy who stands a 2% chance of recovering if somebody spends $200k on cancer therapy, then that may very well be the right decision from my standpoint. On the other hand, the poor kid who needs a heart transplant that has a 90% likelihood of a long and happy life and can't afford one might feel differently about where that $200k should go.
Stick a php_info in your code or something equivalent. I don't believe the FBI was claiming that they received traffic from a non-tor IP, but rather that they received an IP address somewhere in the data sent over tor.
Nothing in tor prevents you from sending your name, address, and social security number in the html of a webpage that you serve. If I wanted to depend on a website remaining anonymous over tor I'd probably stick the entire thing on a private network (with private IPs) such that none of the machines ever contained identifying information (including traceable machine IDs or MACs/etc), heavily firewall it, and carefully control that nothing goes out except via tor. I'd treat every device on the network as if it were compromised and intentionally trying to communicate out every bit of data stored within, so it would be essential that none of these devices contain any information worth stealing.
It's not supposed to do that. It's an INIT system. If you want a daemon manager, the init system can start one for you.
What daemon manager solves those problems? And what is the point of having an init that basically does nothing but spawn a daemon manager and a few gettys? Why not just move that code into the kernel (oh wait, it is already there - it launches init)?
If your daemon manager really did do all the stuff you want it to do, and it dies, then the effects would be about the same as init crashing anyway.