Oh, look! In the cleverly disguised "Migration Planning Guide", there is a section titled "2.2.5. Changed mount behavior at boot". And sure enough, it describes exactly the changed fstab behavior the GP experienced.
systemd makes it much more likely that nearly everyone will do it wrong.
You won't do it wrong if you know how systemd works. You'll know how systemd works if you read the documentation. If you treat a systemd unit file as another kind of init script, it won't work correctly. If you recognize, from reading the documentation, that a unit file is NOT an init script and has a different way of managing the boot process, you won't have any problems with it. It's that simple.
The problem is there are a lot of old init scripts that have to be properly migrated and distro maintainers are relying on a transition helper utility (the systemd-sysv-generator) in the interim. It works, but it is an ugly hack and it sometimes creates problems that would be avoided if there were a proper systemd unit file in place.
No ssh, no nothing. If the server had been remote, this would have been a major issue, instead of a couple of uncomfortable hours (restarting from backups would have been possible but would have changed a quasi-routine thing into one or more days of work).
Look, shame on your distro for not giving you better tools to migrate your/etc/fstab, but the local-fs.target is well-documented. A simple "man systemd.mount" would have told you everything you needed to know and be aware of before upgrading.
Nothing pertinent to the error was logged. Feel free to not believe it.
I don't believe it. Feel free to provide details on how you were looking through the logs.
It did not fail to a recovery shell after being left overnight.
There is a way to boot into an emergency shell when this happens.
Your attitude is part of why systemd is so reviled.
I could say the same about yours. I mean, the parsing of fstab by the local-fs.target is VERY well documented. And so are the early boot debugging features. Why would you upgrade a system before at least taking a cursory look at the documentation? I successfully migrated a moderately complex system dependent on an external ZFS disk array, several NFS exports, and LXC containers+VMs with only a few simple problems that were easy to resolve, but it did require reading some documentation.
although I'd love to see the actual files in some obvious directory
> man systemd.unit
In the section titled "Unit File Load Path": Table 1. Load path when running in system mode (--system). Path Description/etc/systemd/system Local configuration/run/systemd/system Runtime units/usr/lib/systemd/system Units of installed packages
Trying to have half a dozen 'linked' systemd units to fire up a half dozen daemons in the right order is really really horrible.
This is because you are applying SysVInit thinking to systemd and expecting them to work equivalently. With systemd, you don't specify an "order" to start services. You declare dependencies and let systemd handle the ordering.
Trying to make an old init.d script work in systemd is a world of pain.
That really depends on what it is. If you have a bunch of logic embedded in your init script, then you have to take the time to pull all of that out and hook into the appropriate systemd mechanisms. But if you are just creating a socket and a PID file, this is very easy.
I want to look at the bloomin' log because I've forgotten the command line options because I don't use them often enough.
Well, if you just use journalctl all the time, instead of some of the time, maybe you would be more familiar and comfortable with it. If you have scripts that parse the log, you are definitely better off using the journalctl interface rather than grep/sed/awk. You can actually get real-time reporting, rather than just polling the log for changes.
It doesn't seem to suck up STDOUT/STDERR when you really need it to, it doesn't seem to tell you the command it ran that it thought had failed when you want it to, it doesn't give you the response code, it doesn't tell you why it considered it failed, etc etc.
It does all of those things. You just need to learn how to use the tools. For starters try, > journalctl -b -u -o verbose
Depending on systemd version you have to create overrides, modify symlinks or edit systemd files straight up which can be in about 5 different locations and on top of that, systemd can have overrides on any changes either with an update or just inherited.
Nope. First, you should never modify symlinks. Second, if you are looking for/creating a unit file, you only need to look in two locations:/lib/systemd/system -- for unit files that belong to packages./etc/systemd/system -- for unit files that are customized for the local system, these can override unit files found in the above.
Pretty simple and straightforward, actually.
Remove/fail a hard drive and your system will boot into single user mode
If you have a non-essential hard disk in fstab, you should specify "nofail" in the options field. It's right there in the second paragraph under FSTAB of the FM, https://manpages.debian.org/st...
For instance, often systemctl reports a daemon as failed while it's not, or suddenly decides that it didn't start because of some mysterious arbitrary timeout while the daemon just needs some time to run a maintenance tasks at startup time.
If you don't write your systemd unit files correctly, you can't blame systemd.
but I've been doing sysadmin work as an aside (unavoidable in small companies) more or less continuously for the last 30 years.
So, you've been doing sysadmin work for 30 years and decided that a major change to the init system was something you could just upgrade without a second thought? Without reading some docs? Or taking some time to learn how these things would change how you manage the system? Or learn the failure modes of the boot process and the debug utilities available?
Good thing this wasn't a production server. Sheesh.
The problem with systemd is that although it does init systems *better* than everything else*, it's also trying to take over half a dozen more responsibilities that are none of its damn business.
The only thing it "takes over" that some people seem to take exception to is the system log, and it does it for its own purposes. Yes, it can be argued that it would have been better to work with the generic syslog interface, but that just wasn't going to work. They would have had to rewrite large portions of it anyway that would have broken backwards-compatibility, so they just went with their own logging daemon instead, and they did their best to maintain backwards-compatibility by forwarding the log messages to the standard interface. Seems like a pretty reasonable decision to me. The other stuff--NFS, DNS, NTP, etc--is optional, and actually NOT recommended for general use. The standard system utilities are used unless you explicitly override them.
systemd fails silently if something is wrong in/etc/fstab. It just doesn't finish booting. Which is moderately annoying if you have access to the system console and you can guess that an unchanged/etc/fstab from before systemd that worked for a while with systemd is now suddenly toxic
It retries for a bit, but it DOES eventually fail and kick you out to a recovery shell. It just doesn't do it immediately because it assumes that the device may just need some time to come up.
Thanks to the binary log files you cannot even boot something random and read the logs,
What do you mean "boot something random"? I don't see why a generic recovery disk can't have journalctl installed. How about a Debian install disk?
but at least you aren't missing anything, because nothing pertinent to the error is logged anyway.
Not true at all. If you don't know how to use journalctl, that's on you.
There are plenty of people using Perl on shared hosts, so it really shouldn't be a problem. As far as modules go, I can't imagine what would be available in a default PHP that wouldn't be provided for Perl on a shared host, but there are plenty of ways to install local modules if need be. Heck, you can even install a full Perl distribution locally and avoid the system Perl entirely, which is something you cannot do with PHP. Also, Perl had CGI::Application (http://search.cpan.org/~markstos/CGI-Application-4.50/lib/CGI/Application.pm) long before PHP had CakePHP or Zend. A decade ago MVC frameworks were the new hotness, and Perl had Catalyst, which was quite comparable to CakePHP.
Perhaps. I haven't had time to mess around with it yet, but I've been meaning to. The problem is Perl6 is a clean break from Perl5, so it is only useful for new projects. If you are working with legacy code, you have to stick with Perl5. And there are also a ton of useful packages that are not yet available for Perl6.
Also, while Larry did screw around a bit, the delay wasn't entirely his fault. There were a few groups writing competing specs/implementations, and rewriting them, before they finally settled on Larry's spec and the Rakudo implementation.
Although giving the root account an invalid shell will also break single user mode and various system functions, possibly even preventing the system from booting.
Are you sure about that? I admit I haven't tried it, but I don't see why it wouldn't work. The only reason to consult/etc/passwd would be to authenticate the root account, which pam_unix treats as disabled if the password is blank. Su and login require a valid shell entry, but AFAIK nothing else does. Sudo doesn't require the root user to have a shell, and neither does init. So it seems like pretty good insurance to me. If, for example, somebody sets nullok in pam.conf allowing the root user to login with a blank password, the invalid shell entry will block it.
You are right that it would break single-user mode, but you can probably fix that by editing your init script.
This is incorrect. LOGGING IN AS ROOT is disabled. You can still trivially get to be root from a user account in terminal by typing "sudo su" and pressing enter then entering the USER password when prompted.
Yes, you are correct. What I meant was any login (invoking the standard pam_unix module) to the root account is disabled, which includes "su root". Sudo works because it uses the setuid bit to elevate your permissions without first authenticating the root account. It is a convenient method to allow people to run programs as root without logging in as root, and linux distributions such as Ubuntu have been setting up the userland that way by default for many years. It works pretty well as long as you have a properly configured/etc/sudoers file.
No, by default the root account is disabled, but it's there.
This smells like a misconfigured PAM. Apple does a lot of weird and non-standard stuff with the *nix user land, so they probably introduced the vulnerability that way. An improperly configured PAM stack can, for example, try a particular auth mechanism a preconfigured number of times before moving to the next auth mechanism. That fallback mechanism could be the Apple directory service, which doesn't handle the root user and leaves it to the system, but ignores the *nix convention that a passwordless entry in/etc/passwd is a disabled account. Not sure exactly what is happening and don't have a system to test on.
Best workaround is to set the shell of the root user to/bin/false. That will block any attempt to get an interactive login.
Yeah, and like you just said, that peering agreement is between level3 and Comcast, not Comcast and Netflix. If Comcast is no longer happy with that agreement, they are free to renegotiate it with level3, which will then likely pass on the additional costs to its customers, including Netflix. They can also throttle the bandwidth coming from level3 to enforce the agreement, which wil adversely affect all of level3's customers, including Netflix. And then level3 can then choose to do something about that, maybe by enforcing bandwidth caps, for example. Netflix can respond to that by paying Comcast to host their CDN, which would be cheaper (maybe) than paying level3's bandwidth cap penalty. Etc etc...
All of these are perfectly fine free market contract adjustments, where the contract service is defined as "connection to the Internet to send X data and receive Y data for Z price." If at any time the terms of the contract are exceeded, or one member of the party wants to change the contract, there is nothing wrong with that. The problem is that Comcast does not have a contract with Netflix and wants to force them into one so that it can make money off of Netflix's successful business. It is quite literally a protection racket ("those are some nice bits you have there...wouldn't want anything to happen to them, eh?"), and that is what net neutrality is meant to stop.
Hate to point out the obvious, but the true problem is Americans being too fucking lazy to maintain their health through diet and exercise. If they simply did this, there would be no reason to be demanding magical pills to fix a preventable problem.
The way I see it, there are three major contributors:
1) The majority of new development in the US is centered around the automobile. We collectively spend way more time in our cars and our air-conditioned homes and office buildings than ever before. The best way to get people to exercise more is to make it easy and pleasant. Make cities more walkable, create green spaces, make neighborhoods more neighborhood-like (ie: less suburban sprawl and more local amenities and services). Do your kids walk/ride bikes to school, or do you drive them? It is no coincidence that older cities like New York, Boston, DC, etc have better stats with respect to obesity and diabetes occurrence.
2) Childhood obesity. We learn our primary eating habits as children. Whatever you can do to encourage healthy eating for children, whether that be cooking lessons, less junk food, cucumbers and tomatoes instead of mac n' cheese for breakfast, is improvement. The problem is, if you are addicted to fast food, soda, and cheetos before you are 15 years old, it is really hard to change those habits when it starts catching up to you.
3) Time to cook/eat proper meals. True fact: not everybody likes to cook and will do that. But, if you can reliably work a 40-hour week, you might actually be able to spend some time eating properly, rather than grabbing the high-salt high-carb heavily processed food so you can quickly eat and run. If you cook your own meals it is cheaper and healthier for you in the long run, but you don't have to cook to be healthy. You just need healthy options available and affordable, but that requires time.
That's not really what they're saying. They are saying if you can't replace your own brake fluid or cabin air filter, or take it to a Firestone to do it, they will charge you $700 for it, which isn't terribly unlike any other luxury car service. What they don't tell you is how much they spent on oil changes, or transmission fluid, or brake service. Hint: they didn't spend anything on it. So including the savings on gas, that's a good deal less than an ice.
For example, with all hype and features, OS/2 would crash on 3rd party hardware.
Windows was definitely not less bad than OS/2 in this regard. The difference was that Windows was cheaper and they had OEM bundling early on, which led to better support from vendors (hardware and software). From there it just snowballed. This is how Microsoft won. They didn't have a technically superior product, they just anticipated the market better and aggressively pushed their software out to as many people as they could reach while simultaneously locking out their competition wherever possible.
Novell, while working great for DOS systems, was unusable for Windows. And their push for IPX was not scaling well for multi-site networks.
Not sure what you mean. NetWare had a client for Windows that worked fine, and NetWare did move eventually move to TCP/IP, albeit a bit late in the game. The problem was that Microsoft was able to vastly undercut them on price, which was a great success for the SMB market. For the large network market, most stayed with Novell (or Unix) for some time, but as WinNT matured it started to take over because of the excellent bundling packages Microsoft offered. I think Novell could have recovered if the company had been better managed. They should have split off the key NetWare services (NDS, NSS, NDPS, etc) from NetWare much earlier to compete with Microsoft offerings. WinNT might have been better for file and print services, but NDS remained superior to AD for quite some time, you just couldn't buy it as a standalone package. GroupWise was waaaay better than Exchange, but it was a lot more expensive and required NetWare.
The office alternatives took a very long while to switch to Windows. By that time all new typesetters were pretty much used to Office.
Agreed. That was the beginning of their downfall. That and, again, price. WordPerfect when it was ported was just too expensive, and bulk discounts were not offered to schools to universities the way they were for Office.
Basically people underestimated Windows. It had flaws, it would get blue screens, connecting to the Internet would crash it. However it was the only consumer OS that was good enough for the right price at the time
I don't know, I happily used WordPerfect for as long as I could, until Office file compatibility became impossible to avoid. I think Microsoft just succeeded at marketing. They offered discounts. They offered bundling. They practically gave away the stripped down Microsoft Works. File formats became a big issue because competitors couldn't properly render and save Office documents. The likes of WordPerfect probably could have settled at some non-majority fraction of total market share, but file format compatibility killed them. There's a reason why the EC making a strong recommendation to support an open XML-based file format was a big deal for Microsoft.
I don't think he wants housing to be more expensive. I know I certainly don't. The policy of having a mortgage interest deduction is actually artificially raising housing prices.
That is very debatable.
Either eliminate the restrictions that force kids to only be able to attend their local public schools, or ensure that every public school has equal resources.
Two points:
1) Busing kids around is expensive, and impractical on a large scale. Schools need to be local for a lot of other reasons too, such as integration into the community and to facilitate interactions with parents.
2) If you had said "ensure every public school is of comparable caliber", I would agree, but you are assuming money is the only issue. It isn't.
I really don't see a good reason to support a policy that only benefits the top 20%.
Every policy benefits only a fraction of people. You need to consider each policy individually, not just the fraction of people it benefits. The progressive income tax benefits the bottom tax brackets who definitely need that extra income, so I don't have a problem with that.
I think many people in the top 20% do this because they worked so hard to get there, that they want to protect what they've worked so hard to get. But this is not fair to everyone.
The problem is correlation, but not causation. The mortgage interest deduction benefits everybody who owns a house, who are more than just the top 20%. The disparity is not because it is a benefit for only the top 20%, but because the top 20% own more expensive houses and therefore get a higher deduction than those who own less expensive houses. The problem with aggregated national averages is that the majority of our everyday living is enabled by transactions within local markets, and different local markets often present very different real world circumstances. A $100k/yr gross income puts you in the top 20% nationally. In Houston, housing prices are low enough that you can buy a very nice house in a very nice neighborhood with good schools for $300k, which is just above the median house price for the area. The top 20% can afford that easily, and probably don't need the mortgage interest deduction. The top 40% can probably still afford it, but those lower in the income bracket will struggle a bit and the mortgage interest deduction helps them out a lot. In Boston, a much smaller house in a good neighborhood will cost you at least $800k, which is much less than the median house price in many of those neighborhoods. For these the top 20% can barely afford the house, if at all, and those who can definitely need the mortgage interest deduction.
Top 0.1%ers managed to get a tax break on private jets. This is not in the interest of anyone but the ultra wealthy.
A private jet is a very different thing from a house, unless it is an investment property. I agree that the mortgage interest deduction should not go to somebody who already owns a primary residence.
If you are actively working to keep the system the way it is rather than being open to making it more fair, simply because it benefits you, then you are a hoarder.
Fairness is tricky to define objectively. Disparities exist and probably always will. I think it is hazardous to judge fairness on the basis of oversimplified metrics, such as income tax brackets. Affordable healthcare and good schools in affordable neighborhoods should be accessible to everyone and they ultimately benefit everyone regardless of income status. How do we get there? Maybe we do have to increase the tax base in some cases, but these are complex problems that require careful thought.
but all I'm talking about is not having a bunch of loopholes for the people who do attain some level of wealth whether it's 20%, 1%, 0.1%, etc.
Microsoft wasn't bad technically, but they got where they were in the mid-90's in large part because of Bill Gates' ruthless business instincts.
The latter part of your statement is correct, but Microsoft was definitely bad technically. Both Windows and Office in the 95/98 days were terrible products, that they succeeded in spite of, not because of. This was especially true around the time they were pushing their networking stuff for SMBs. It was a total joke compared to Novell, but they succeeded.
Slashdot Mirror
Uh...there are quite a lot of official documentation repositories you can look at, including this very good one,
https://wiki.archlinux.org/ind...
And this one,
https://access.redhat.com/docu...
Oh, look! In the cleverly disguised "Migration Planning Guide", there is a section titled "2.2.5. Changed mount behavior at boot". And sure enough, it describes exactly the changed fstab behavior the GP experienced.
systemd makes it much more likely that nearly everyone will do it wrong.
You won't do it wrong if you know how systemd works. You'll know how systemd works if you read the documentation. If you treat a systemd unit file as another kind of init script, it won't work correctly. If you recognize, from reading the documentation, that a unit file is NOT an init script and has a different way of managing the boot process, you won't have any problems with it. It's that simple.
The problem is there are a lot of old init scripts that have to be properly migrated and distro maintainers are relying on a transition helper utility (the systemd-sysv-generator) in the interim. It works, but it is an ugly hack and it sometimes creates problems that would be avoided if there were a proper systemd unit file in place.
Maybe because you said it yourself?
No ssh, no nothing. If the server had been remote, this would have been a major issue, instead of a couple of uncomfortable hours (restarting from backups would have been possible but would have changed a quasi-routine thing into one or more days of work).
Look, shame on your distro for not giving you better tools to migrate your /etc/fstab, but the local-fs.target is well-documented. A simple "man systemd.mount" would have told you everything you needed to know and be aware of before upgrading.
Nothing pertinent to the error was logged. Feel free to not believe it.
I don't believe it. Feel free to provide details on how you were looking through the logs.
It did not fail to a recovery shell after being left overnight.
There is a way to boot into an emergency shell when this happens.
Your attitude is part of why systemd is so reviled.
I could say the same about yours. I mean, the parsing of fstab by the local-fs.target is VERY well documented. And so are the early boot debugging features. Why would you upgrade a system before at least taking a cursory look at the documentation? I successfully migrated a moderately complex system dependent on an external ZFS disk array, several NFS exports, and LXC containers+VMs with only a few simple problems that were easy to resolve, but it did require reading some documentation.
although I'd love to see the actual files in some obvious directory
> man systemd.unit
In the section titled "Unit File Load Path": /etc/systemd/system Local configuration /run/systemd/system Runtime units /usr/lib/systemd/system Units of installed packages
Table 1. Load path when running in system mode (--system).
Path Description
Trying to have half a dozen 'linked' systemd units to fire up a half dozen daemons in the right order is really really horrible.
This is because you are applying SysVInit thinking to systemd and expecting them to work equivalently. With systemd, you don't specify an "order" to start services. You declare dependencies and let systemd handle the ordering.
Trying to make an old init.d script work in systemd is a world of pain.
That really depends on what it is. If you have a bunch of logic embedded in your init script, then you have to take the time to pull all of that out and hook into the appropriate systemd mechanisms. But if you are just creating a socket and a PID file, this is very easy.
I want to look at the bloomin' log because I've forgotten the command line options because I don't use them often enough.
Well, if you just use journalctl all the time, instead of some of the time, maybe you would be more familiar and comfortable with it. If you have scripts that parse the log, you are definitely better off using the journalctl interface rather than grep/sed/awk. You can actually get real-time reporting, rather than just polling the log for changes.
It doesn't seem to suck up STDOUT/STDERR when you really need it to, it doesn't seem to tell you the command it ran that it thought had failed when you want it to, it doesn't give you the response code, it doesn't tell you why it considered it failed, etc etc.
It does all of those things. You just need to learn how to use the tools. For starters try,
> journalctl -b -u -o verbose
Ever tried to edit systemd files?
Yes. But I did have to read some documentation.
Depending on systemd version you have to create overrides, modify symlinks or edit systemd files straight up which can be in about 5 different locations and on top of that, systemd can have overrides on any changes either with an update or just inherited.
Nope. First, you should never modify symlinks. Second, if you are looking for/creating a unit file, you only need to look in two locations: /lib/systemd/system -- for unit files that belong to packages. /etc/systemd/system -- for unit files that are customized for the local system, these can override unit files found in the above.
Pretty simple and straightforward, actually.
Remove/fail a hard drive and your system will boot into single user mode
If you have a non-essential hard disk in fstab, you should specify "nofail" in the options field. It's right there in the second paragraph under FSTAB of the FM,
https://manpages.debian.org/st...
For instance, often systemctl reports a daemon as failed while it's not, or suddenly decides that it didn't start because of some mysterious arbitrary timeout while the daemon just needs some time to run a maintenance tasks at startup time.
If you don't write your systemd unit files correctly, you can't blame systemd.
but I've been doing sysadmin work as an aside (unavoidable in small companies) more or less continuously for the last 30 years.
So, you've been doing sysadmin work for 30 years and decided that a major change to the init system was something you could just upgrade without a second thought? Without reading some docs? Or taking some time to learn how these things would change how you manage the system? Or learn the failure modes of the boot process and the debug utilities available?
Good thing this wasn't a production server. Sheesh.
The problem with systemd is that although it does init systems *better* than everything else*, it's also trying to take over half a dozen more responsibilities that are none of its damn business.
The only thing it "takes over" that some people seem to take exception to is the system log, and it does it for its own purposes. Yes, it can be argued that it would have been better to work with the generic syslog interface, but that just wasn't going to work. They would have had to rewrite large portions of it anyway that would have broken backwards-compatibility, so they just went with their own logging daemon instead, and they did their best to maintain backwards-compatibility by forwarding the log messages to the standard interface. Seems like a pretty reasonable decision to me. The other stuff--NFS, DNS, NTP, etc--is optional, and actually NOT recommended for general use. The standard system utilities are used unless you explicitly override them.
systemd fails silently if something is wrong in /etc/fstab. It just doesn't finish booting. Which is moderately annoying if you have access to the system console and you can guess that an unchanged /etc/fstab from before systemd that worked for a while with systemd is now suddenly toxic
It retries for a bit, but it DOES eventually fail and kick you out to a recovery shell. It just doesn't do it immediately because it assumes that the device may just need some time to come up.
Thanks to the binary log files you cannot even boot something random and read the logs,
What do you mean "boot something random"? I don't see why a generic recovery disk can't have journalctl installed. How about a Debian install disk?
but at least you aren't missing anything, because nothing pertinent to the error is logged anyway.
Not true at all. If you don't know how to use journalctl, that's on you.
There are plenty of people using Perl on shared hosts, so it really shouldn't be a problem. As far as modules go, I can't imagine what would be available in a default PHP that wouldn't be provided for Perl on a shared host, but there are plenty of ways to install local modules if need be. Heck, you can even install a full Perl distribution locally and avoid the system Perl entirely, which is something you cannot do with PHP. Also, Perl had CGI::Application (http://search.cpan.org/~markstos/CGI-Application-4.50/lib/CGI/Application.pm) long before PHP had CakePHP or Zend. A decade ago MVC frameworks were the new hotness, and Perl had Catalyst, which was quite comparable to CakePHP.
Wait...really?
Perl is a PITA because you have to write "#! /usr/bin/env perl" at the top of your script instead of just mashing out a bunch of html mixed with code?
Perhaps. I haven't had time to mess around with it yet, but I've been meaning to. The problem is Perl6 is a clean break from Perl5, so it is only useful for new projects. If you are working with legacy code, you have to stick with Perl5. And there are also a ton of useful packages that are not yet available for Perl6.
Also, while Larry did screw around a bit, the delay wasn't entirely his fault. There were a few groups writing competing specs/implementations, and rewriting them, before they finally settled on Larry's spec and the Rakudo implementation.
Someone has a good sense of humor. The Perl6 advent calendar is hosted on a Wordpress site.
Although giving the root account an invalid shell will also break single user mode and various system functions, possibly even preventing the system from booting.
Are you sure about that? I admit I haven't tried it, but I don't see why it wouldn't work. The only reason to consult /etc/passwd would be to authenticate the root account, which pam_unix treats as disabled if the password is blank. Su and login require a valid shell entry, but AFAIK nothing else does. Sudo doesn't require the root user to have a shell, and neither does init. So it seems like pretty good insurance to me. If, for example, somebody sets nullok in pam.conf allowing the root user to login with a blank password, the invalid shell entry will block it.
You are right that it would break single-user mode, but you can probably fix that by editing your init script.
This is incorrect. LOGGING IN AS ROOT is disabled. You can still trivially get to be root from a user account in terminal by typing "sudo su" and pressing enter then entering the USER password when prompted.
Yes, you are correct. What I meant was any login (invoking the standard pam_unix module) to the root account is disabled, which includes "su root". Sudo works because it uses the setuid bit to elevate your permissions without first authenticating the root account. It is a convenient method to allow people to run programs as root without logging in as root, and linux distributions such as Ubuntu have been setting up the userland that way by default for many years. It works pretty well as long as you have a properly configured /etc/sudoers file.
No, by default the root account is disabled, but it's there.
This smells like a misconfigured PAM. Apple does a lot of weird and non-standard stuff with the *nix user land, so they probably introduced the vulnerability that way. An improperly configured PAM stack can, for example, try a particular auth mechanism a preconfigured number of times before moving to the next auth mechanism. That fallback mechanism could be the Apple directory service, which doesn't handle the root user and leaves it to the system, but ignores the *nix convention that a passwordless entry in /etc/passwd is a disabled account. Not sure exactly what is happening and don't have a system to test on.
Best workaround is to set the shell of the root user to /bin/false. That will block any attempt to get an interactive login.
Yeah, and like you just said, that peering agreement is between level3 and Comcast, not Comcast and Netflix. If Comcast is no longer happy with that agreement, they are free to renegotiate it with level3, which will then likely pass on the additional costs to its customers, including Netflix. They can also throttle the bandwidth coming from level3 to enforce the agreement, which wil adversely affect all of level3's customers, including Netflix. And then level3 can then choose to do something about that, maybe by enforcing bandwidth caps, for example. Netflix can respond to that by paying Comcast to host their CDN, which would be cheaper (maybe) than paying level3's bandwidth cap penalty. Etc etc...
All of these are perfectly fine free market contract adjustments, where the contract service is defined as "connection to the Internet to send X data and receive Y data for Z price." If at any time the terms of the contract are exceeded, or one member of the party wants to change the contract, there is nothing wrong with that. The problem is that Comcast does not have a contract with Netflix and wants to force them into one so that it can make money off of Netflix's successful business. It is quite literally a protection racket ("those are some nice bits you have there...wouldn't want anything to happen to them, eh?"), and that is what net neutrality is meant to stop.
Hate to point out the obvious, but the true problem is Americans being too fucking lazy to maintain their health through diet and exercise. If they simply did this, there would be no reason to be demanding magical pills to fix a preventable problem.
The way I see it, there are three major contributors:
1) The majority of new development in the US is centered around the automobile. We collectively spend way more time in our cars and our air-conditioned homes and office buildings than ever before. The best way to get people to exercise more is to make it easy and pleasant. Make cities more walkable, create green spaces, make neighborhoods more neighborhood-like (ie: less suburban sprawl and more local amenities and services). Do your kids walk/ride bikes to school, or do you drive them? It is no coincidence that older cities like New York, Boston, DC, etc have better stats with respect to obesity and diabetes occurrence.
2) Childhood obesity. We learn our primary eating habits as children. Whatever you can do to encourage healthy eating for children, whether that be cooking lessons, less junk food, cucumbers and tomatoes instead of mac n' cheese for breakfast, is improvement. The problem is, if you are addicted to fast food, soda, and cheetos before you are 15 years old, it is really hard to change those habits when it starts catching up to you.
3) Time to cook/eat proper meals. True fact: not everybody likes to cook and will do that. But, if you can reliably work a 40-hour week, you might actually be able to spend some time eating properly, rather than grabbing the high-salt high-carb heavily processed food so you can quickly eat and run. If you cook your own meals it is cheaper and healthier for you in the long run, but you don't have to cook to be healthy. You just need healthy options available and affordable, but that requires time.
If you're referring to this article,
https://www.caranddriver.com/r...
That's not really what they're saying. They are saying if you can't replace your own brake fluid or cabin air filter, or take it to a Firestone to do it, they will charge you $700 for it, which isn't terribly unlike any other luxury car service. What they don't tell you is how much they spent on oil changes, or transmission fluid, or brake service. Hint: they didn't spend anything on it. So including the savings on gas, that's a good deal less than an ice.
For example, with all hype and features, OS/2 would crash on 3rd party hardware.
Windows was definitely not less bad than OS/2 in this regard. The difference was that Windows was cheaper and they had OEM bundling early on, which led to better support from vendors (hardware and software). From there it just snowballed. This is how Microsoft won. They didn't have a technically superior product, they just anticipated the market better and aggressively pushed their software out to as many people as they could reach while simultaneously locking out their competition wherever possible.
Novell, while working great for DOS systems, was unusable for Windows. And their push for IPX was not scaling well for multi-site networks.
Not sure what you mean. NetWare had a client for Windows that worked fine, and NetWare did move eventually move to TCP/IP, albeit a bit late in the game. The problem was that Microsoft was able to vastly undercut them on price, which was a great success for the SMB market. For the large network market, most stayed with Novell (or Unix) for some time, but as WinNT matured it started to take over because of the excellent bundling packages Microsoft offered. I think Novell could have recovered if the company had been better managed. They should have split off the key NetWare services (NDS, NSS, NDPS, etc) from NetWare much earlier to compete with Microsoft offerings. WinNT might have been better for file and print services, but NDS remained superior to AD for quite some time, you just couldn't buy it as a standalone package. GroupWise was waaaay better than Exchange, but it was a lot more expensive and required NetWare.
The office alternatives took a very long while to switch to Windows. By that time all new typesetters were pretty much used to Office.
Agreed. That was the beginning of their downfall. That and, again, price. WordPerfect when it was ported was just too expensive, and bulk discounts were not offered to schools to universities the way they were for Office.
Basically people underestimated Windows. It had flaws, it would get blue screens, connecting to the Internet would crash it. However it was the only consumer OS that was good enough for the right price at the time
edits mine
I don't know, I happily used WordPerfect for as long as I could, until Office file compatibility became impossible to avoid. I think Microsoft just succeeded at marketing. They offered discounts. They offered bundling. They practically gave away the stripped down Microsoft Works. File formats became a big issue because competitors couldn't properly render and save Office documents. The likes of WordPerfect probably could have settled at some non-majority fraction of total market share, but file format compatibility killed them. There's a reason why the EC making a strong recommendation to support an open XML-based file format was a big deal for Microsoft.
Uhhh...how about WordPerfect 5.2 for Windows? Lotus? Appleworks?
I don't think he wants housing to be more expensive. I know I certainly don't. The policy of having a mortgage interest deduction is actually artificially raising housing prices.
That is very debatable.
Either eliminate the restrictions that force kids to only be able to attend their local public schools, or ensure that every public school has equal resources.
Two points:
1) Busing kids around is expensive, and impractical on a large scale. Schools need to be local for a lot of other reasons too, such as integration into the community and to facilitate interactions with parents.
2) If you had said "ensure every public school is of comparable caliber", I would agree, but you are assuming money is the only issue. It isn't.
I really don't see a good reason to support a policy that only benefits the top 20%.
Every policy benefits only a fraction of people. You need to consider each policy individually, not just the fraction of people it benefits. The progressive income tax benefits the bottom tax brackets who definitely need that extra income, so I don't have a problem with that.
I think many people in the top 20% do this because they worked so hard to get there, that they want to protect what they've worked so hard to get. But this is not fair to everyone.
The problem is correlation, but not causation. The mortgage interest deduction benefits everybody who owns a house, who are more than just the top 20%. The disparity is not because it is a benefit for only the top 20%, but because the top 20% own more expensive houses and therefore get a higher deduction than those who own less expensive houses. The problem with aggregated national averages is that the majority of our everyday living is enabled by transactions within local markets, and different local markets often present very different real world circumstances. A $100k/yr gross income puts you in the top 20% nationally. In Houston, housing prices are low enough that you can buy a very nice house in a very nice neighborhood with good schools for $300k, which is just above the median house price for the area. The top 20% can afford that easily, and probably don't need the mortgage interest deduction. The top 40% can probably still afford it, but those lower in the income bracket will struggle a bit and the mortgage interest deduction helps them out a lot. In Boston, a much smaller house in a good neighborhood will cost you at least $800k, which is much less than the median house price in many of those neighborhoods. For these the top 20% can barely afford the house, if at all, and those who can definitely need the mortgage interest deduction.
Top 0.1%ers managed to get a tax break on private jets. This is not in the interest of anyone but the ultra wealthy.
A private jet is a very different thing from a house, unless it is an investment property. I agree that the mortgage interest deduction should not go to somebody who already owns a primary residence.
If you are actively working to keep the system the way it is rather than being open to making it more fair, simply because it benefits you, then you are a hoarder.
Fairness is tricky to define objectively. Disparities exist and probably always will. I think it is hazardous to judge fairness on the basis of oversimplified metrics, such as income tax brackets. Affordable healthcare and good schools in affordable neighborhoods should be accessible to everyone and they ultimately benefit everyone regardless of income status. How do we get there? Maybe we do have to increase the tax base in some cases, but these are complex problems that require careful thought.
but all I'm talking about is not having a bunch of loopholes for the people who do attain some level of wealth whether it's 20%, 1%, 0.1%, etc.
One person calls
Microsoft wasn't bad technically, but they got where they were in the mid-90's in large part because of Bill Gates' ruthless business instincts.
The latter part of your statement is correct, but Microsoft was definitely bad technically. Both Windows and Office in the 95/98 days were terrible products, that they succeeded in spite of, not because of. This was especially true around the time they were pushing their networking stuff for SMBs. It was a total joke compared to Novell, but they succeeded.