Given the workaround in windows is as simple as literally using *anything* other than notepad (get-content, wordpad, really *anything* but notepad understands '\n' by itself implies '\r')
So you need to install extra tools... I don't see how that's different.
And besides, how do you grep through Unix logfiles on Windows anyway? Oh yeah, install extra third-party tools from somewhere....
EDBDIC is a good example of how IBM has certain things screwed up in mainframe world, so I don't think holding that up as a shining example of what works for justifying a proprietary format.
There's nothing "screwed up" about it, it's simply a different encoding. There's nothing sacrosanct about ASCII, it just happens to be the most popular encoding, which makes it a de-facto standard, but it's not the only way to encode text.
My point is today 'xz' is modern place on 'modern systems'. 6 months from now, there is something else that will be 'commonplace' and therefore might as well make it a hard requirement. It's churn without sufficient benefit to justify it.
xz performs better than gzip; that alone justifies its use. It's not like it takes a lot of hard drive space. And it hasn't replaced gzip; every system still has gzip installed, along with bzip2, even though the latter has fallen out of use (and never was used that much to begin with). And IIRC, gzip still decompresses.Z files. Everything is backwards-compatible. Who cares if there's something else later, as long as backwards compatibility is maintained? And it's not like we've had a plethora of compression tools in the last decade anyway. ZIP and RAR go back to the early 90s, there's some truly ancient formats from before then in the DOS world (like.zoo) but in the Linux world of the last 10-15 years there's only been gzip, bzip2, (both over 10 years old) and now xz. So really, we've only had one new tool in the last decade.
I might want to pop a drive from a failed system into an external enclosure attached to my CentOS 6 workstation.
That's why you don't use ancient systems to work on newer systems. Try reading a bzip2 file on some ~1996 Slackware system; if you want to use newer stuff, you have to move to newer systems and software. There's nothing new going on here besides the normal progression of technology and standards, you're just complaining because someone is trying to introduce a new standard and you never want to change anything, at all, ever.
This language sounds like the sort of language MS would use to justify eventviewer. "All editions of *windows* will have it and that's all that matters". We've had inter-operable logging formats and facilities for decades in the *nix world,
No, we haven't. We do exactly the same thing as Windows. We use binary formats that only Linux/Unix systems can easily read, and which Windows systems (among others) cannot. We call these binary formats "plaintext", but they're not, they're a binary format that uses ASCII encoding, with a particular end-of-line standard which is different from that on Windows. We like to call this "plaintext", but it's really a misnomer for a very particular binary encoding standard. (Go back in time and find some sysadmin for an EDBDIC system and ask them what their definition of "plaintext file" is.) So you can't easily view and work with these files on a Windows system (just try opening one of these files in Notepad). Do we care about this? I don't know about you, but I don't; any Linux or Unix system can view Unix-standard text files just fine, and that's all that matters.
The same goes for cases where the file is gzipped; there isn't a Linux system from the last 20 years that doesn't have gzip installed. And on modern systems, xz is commonplace as well.
The only thing that matters is if your data, in whatever format it's in, is easily accessible and manipulatable. For those of us using Unix or Linux, there's various kinds of files which are: "plaintext" (ASCII/Unix EOL), gzipped, bzip2ed, even pkzipped, because these all have easily and universally-available tools to access this data: you can expect any modern Linux system to have these tools installed by default. As long as the tools to view and manipulate systemd logfiles are similarly prevalent (which they will be on any systemd distro, as long as they don't go changing the binary standard for these files), it'll be no different. No, you won't be able to easily copy these files to a Windows system and work with them there (without installing extra tools), but that's no different from today (and why would you want to do that anyway?).
>You get tools to do some more sophisticated things to log files, but if you find yourself with the data in a place without ready access to those tools, you will be out of luck.
As long as the logfiles are standardized, this shouldn't be a problem. Do I worry if I need to look at a.zip file or a.tar.gz or.tar.bz2 file? Of course not, because any Linux system has the tools available to view these archives. The only real problem is if I want to view something like a.tar.gz on a Windows system, but even viewing and editing text files is problematic on Windows since it uses a different line-ending standard than Unix and Linux systems, so you can't even claim that those plaintext logfiles can be viewed anywhere. Try opening plaintext logfiles in Windows Notepad and see what happens. Or try grepping that logfile for some string; oh right, you can't, because Windows doesn't have grep. You're just used to plaintext logfiles because Linux systems all have lots of tools useful for viewing those files and extracting data from them. When Linux systems all (or mostly) have systemd, they'll have the tools useful for viewing systemd logfiles as well.
Imagine if some Linux distro had plaintext logfiles, but they were all gzipped. Would you be complaining about that? How trivial is it to extract data from logfile.gz? Using tools like zgrep, zcat, or regular piping and redirection, it's trivial. It shouldn't (in theory) be any different with systemd logfiles; just use the appropriate tool to extract data in textual form (this tool probably has options to perform useful filtering on the data), and then you can pipe this into something else to process it further.
It seems like the algorithm could be tweaked a little so that if the GPS is showing the car in a river, a forest, a building, etc. instead of driving on a road as DR indicates, then DR should be favored. After all, it simply doesn't make any sense for the vehicle to be in a river. Or, if you're taking an exit ramp, and the GPS signals show the vehicle veering off into the trees while DR just shows the vehicle is proceeding around the curve at a normal rate, then it should be pretty obvious that the vehicle has not, in fact, gone off-road and is driving through metal barriers and trees at 40mph.
So how do you filter out all the extra accelerations from the users dropping the phone on the floor, fiddling with it, moving it around, etc. while the car is in motion? Phones aren't rigidly mounted in cars.
And considering how often Google Maps thinks I've instantly teleported to different places while driving, it doesn't look like all this theory really holds up in reality.
Surely you can use both, even if your DR data is not so great; just use the DR data to verify the GPS data makes sense. If the GPS signals say the vehicle has suddenly teleported into a river, check that against the DR. If the DR data says you're still driving straight, then disregard the GPS data until it agrees with the DR data.
You don't even need to go to all that trouble. That kind of accuracy simply isn't necessary in a car as long as it has GPS. Dead-reckoning, in an in-car navigation system, is only needed to make up for the inaccuracy with GPS, which is mainly because you sometimes lose the signals (inside a parking garage, around too many tall buildings, etc.). You don't normally lose GPS signals for a very long amount of time, only short periods. So DR is just a supplement, and the vehicle's odometer signal alone is enough for supplementation, and an electronic compass signal is even better because this gives you direction, in case you turn the car while your GPS signal is missing. You're not looking for accuracy to the inch or even the foot, 50-foot accuracy is good enough in this application, so compensating for tire pressure is entirely unnecessary; they don't do that for the vehicle's odometer after all. You just need the system to warn you in enough time for you to make the next turn.
Android phones have had the ability to use dead reckoning for years now too.
Citation needed. This sounds like bullshit. You get dead reckoning by connecting to some sort of feedback device, namely the wheel sensors or odometer in the vehicle. Android phones don't have a connection to your car's computer; they work entirely off of GPS signals. In-car nav systems aren't like this; they use both GPS and dead-reckoning to get better accuracy than GPS alone (watch what happens when you drive into a parking garage with a GPS-only device). The problem with in-car nav systems is that they usually have very out-of-date technology otherwise, the maps aren't updated, you have to pay a fortune for updated maps, etc.
1 picture is worth 1000 words. However, the words one person thinks of when they see a picture will be different from the words another person thinks of seeing the same picture. Text is less ambiguous. And text in purely logical languages (like programming languages) is completely unambiguous. When you want exact, deterministic behavior, you need to express yourself in an unambiguous manner.
I just looked at a Dodge that was made in either Indiana or Illinois, I forget which. The American content was around 60-70% (the big exception was the transmission, which came from Korea). No significant part came from China. I think you're making things up.
Intel is not overseas, that's a blatant lie. Most of their fabs are in the US, mainly Oregon and Arizona. They have two 14nm fabs in Oregon and Ireland, 22nm fabs in Oregon, Arizona, and Israel, and their latest fab (14nm 450mm) is being built in Arizona. See here: http://en.wikipedia.org/wiki/L...
The Model F was better, at least for the keyswitch mechanism. They layout was awful though. The keyboard with the best layout is the Sun Type 5 (but the keyswitch mechanism there sucks).
I can name a bunch of things we manufacture here: - aircraft carriers - fighter jets (F-22, F-35) - rifles (M-4) - helicopters (Black Hawk, Apache)
Of course, all this stuff is purchased by the US government, using printed money. If you're looking for stuff that isn't solely for the defense sector, I can only think of a couple of things: Intel CPUs and Boeing passenger jets, along with some automobiles (I think Chryslers are still mostly made in the US).
Contractors also cost a lot more, doubly so when you factor in that you have to keep paying them well past the end of the contract to fix all the screwups.
Yes, but which costs more, over the long term: hiring contractors with these problems, or hiring regular employees who are nearly impossible to get rid of when they're either no longer needed or don't perform?
Right now we have to wait a bit and see if they actually start fixing stuff, which Timothy just tried to convince us about. They cannot add the new code overnight.
They don't need to add any new code, they just need to delete all the Beta code.
Yep, Slashdot is on its last legs. If you're interested in true nerd stuff, you need to go to Reddit, and find particular forums (subreddits) there that you're interested in and subscribe to those. This segregation is something that Slashdot never did very well; it tried to have ways of allowing users to filter the news by category, but it never worked very well. On Reddit, everything's in a different forum, so it's segregated naturally. If you want to read Linux-related stuff, simply go to/r/Linux. If you want to read Microsoft-related crap, just go to/r/Microsoft. If you don't want to read MS-related crap and comments from MS fanboys, then don't go to that subreddit. Of course, this doesn't keep shills from invading/r/Linux, but at least you won't see articles about some stupid new MS product you don't care about. And there's lots of even more highly-focused subreddits, like/r/DDWRT if you're interested in DD-WRT,/r/kernel if you're interested in Linux kernel news,/r/linux_devices for that kind of thing,/r/embeddedlinux for linux on embedded devices, etc. I'm sure there's all kinds of other subreddits for other fields if you're interested or a fan of something, whether it's Apple, Mac, iOS, Blackberry, Android, Google, Oracle, whatever.
I'm pretty close to New England now, and this place seems to love authoritarianism. It's not very liberal at all (they think they're liberal because they tend to vote Democrat, but loving unions does not make you a liberal), the level of corruption is insane, and they have military soldiers with M-16s performing police duties.
I do advocate a break-up, but I think realistically if it does happen, it's going to take a long time, and things will have to get a LOT worse. America still has a lot of imperial power and inertia. Look how long it took the Roman empire to collapse; America's a lot more cohesive than that was (or other empires were); it's actually one single very large country (with some tiny territories, and a lot of military bases scattered about), rather than a small country with a huge amount of possessions where people had totally different languages and cultures.
Instead of spending the rest of my adult working years living through the decline, it seems like it'd be better to move to greener pastures.
I've totally missed the pro-Putin anti-gay stuff, but I guess I shouldn't be surprised. Holy crap I need to get out of this country. Pretty soon we're going to have another Victorian era, only worse. At least in Victorian times people knew how to act polite usually.
Obviously the 50s were a rather primitive time in computing, but I suspect much of the problem was that people at that time just weren't used to writing software, since it was so new. In the 80s, all kinds of stuff was written in assembly language, and it was far more complex than 100 instructions; just look at any of the console games of the era (NES, etc.), programs written for the popular microcomputers at the time (C=64, Apple ][), etc. All that stuff (the high-performance stuff at least) was written in 100% assembly.
Also, going back to the 60s, that was the era of the MULTICS system, as well as UNIX. MULTICS had a lot of features that are still considered high-end today, like being able to hot-swap CPUs and memory. Read more here.. It sounds to me like maybe there was a big divide between the extremely competent engineers of the time (Kernighan, Ritchie, etc.) who designed these systems and the low-level programmers who wrote stuff like payroll calculation programs. It probably didn't help that they hadn't yet developed decent debugging tools, plus for a while a lot of output was done with teletype terminals onto paper rather than with CRT monitors which of course massively slowed down the development and debugging processes.
Anyway, I'm not saying everyone today is incompetent compared to the people of the past, but for many things, it sure does seem like people have gotten less competent at actually producing anything. Are today's aerospace engineers really that incompetent compared to the engineers who built the B-52? Or, more likely, are our organizations more incompetent at managing people and producing results in a decent timeframe? Not everything is dog-slow; Apple seems to have no trouble turning out new products at a fast clip, and CPU manufacturers have done an impressive job of pushing the state-of-the-art over the last 20 years, though they've run into some problems with basic physics lately, but even so are still making impressive gains in MIPS/Watt efficiency, low-power modes, etc. The automotive industry seems to be making some decent gains with engine efficiency lately (I'm seeing mid-size SUVs now exceeding 30mpg), but they went through a period (70s-90s) where the American automakers were producing ridiculously bad cars. The aviation industry is a complete disaster, with companies taking decades to build new planes, and still having embarrassing problems with them. Parts of the software industry aren't doing so hot either; what has Microsoft done lately of note? Produced a re-skinned version of Win7 (which isn't really that much different from XP, almost 15 years old now) which doesn't add any significant new features but has a horrible new UI in a misguided attempt to unify desktop and mobile computing. And it's not just them; UIs all over have gotten worse because of this same trend.
One big problem I see here is the conflation of "IT", "engineering", and "programming". Some of these things do overlap, but not nearly as much as people think they do. A job which involves being on-call does not involve programming; that kind of job is IT support, and probably is what's called a "systems administration" job, or just plain "IT support", or "helpdesk". People who do these jobs do not do 8 hours of programming a day; systems admins might do a little scripting, and that's about it, if they're lucky. The guy you call to help you reset your Active Directory password does not do programming, at all. The people who do programming as a full-time job are not on-call.
If you're a patient, you might want to consider seeking out female surgeons instead of male ones. Not only are women typically considered to have better fine-motor skills than men, if they don't work crazy hours, they're much less likely to fuck up while they've got you cut open and are messing around with a scalpel inside your body. Why the hell would I want some overworked, over-caffeinated person operating on me? That's a recipe for disaster.
8 hours a day at a computer? Gosh, that sounds like most white collar jobs of the last few decades.
Sounds like most non-managerial white collar jobs. The managerial jobs involve sitting in meetings all day long, and for the periods of time where computers are used, they involve printing out every single email and walking back and forth to the printer to get these emails.
Slashdot Mirror
Given the workaround in windows is as simple as literally using *anything* other than notepad (get-content, wordpad, really *anything* but notepad understands '\n' by itself implies '\r')
So you need to install extra tools... I don't see how that's different.
And besides, how do you grep through Unix logfiles on Windows anyway? Oh yeah, install extra third-party tools from somewhere....
EDBDIC is a good example of how IBM has certain things screwed up in mainframe world, so I don't think holding that up as a shining example of what works for justifying a proprietary format.
There's nothing "screwed up" about it, it's simply a different encoding. There's nothing sacrosanct about ASCII, it just happens to be the most popular encoding, which makes it a de-facto standard, but it's not the only way to encode text.
My point is today 'xz' is modern place on 'modern systems'. 6 months from now, there is something else that will be 'commonplace' and therefore might as well make it a hard requirement. It's churn without sufficient benefit to justify it.
xz performs better than gzip; that alone justifies its use. It's not like it takes a lot of hard drive space. And it hasn't replaced gzip; every system still has gzip installed, along with bzip2, even though the latter has fallen out of use (and never was used that much to begin with). And IIRC, gzip still decompresses .Z files. Everything is backwards-compatible. Who cares if there's something else later, as long as backwards compatibility is maintained? And it's not like we've had a plethora of compression tools in the last decade anyway. ZIP and RAR go back to the early 90s, there's some truly ancient formats from before then in the DOS world (like .zoo) but in the Linux world of the last 10-15 years there's only been gzip, bzip2, (both over 10 years old) and now xz. So really, we've only had one new tool in the last decade.
I might want to pop a drive from a failed system into an external enclosure attached to my CentOS 6 workstation.
That's why you don't use ancient systems to work on newer systems. Try reading a bzip2 file on some ~1996 Slackware system; if you want to use newer stuff, you have to move to newer systems and software. There's nothing new going on here besides the normal progression of technology and standards, you're just complaining because someone is trying to introduce a new standard and you never want to change anything, at all, ever.
This language sounds like the sort of language MS would use to justify eventviewer. "All editions of *windows* will have it and that's all that matters". We've had inter-operable logging formats and facilities for decades in the *nix world,
No, we haven't. We do exactly the same thing as Windows. We use binary formats that only Linux/Unix systems can easily read, and which Windows systems (among others) cannot. We call these binary formats "plaintext", but they're not, they're a binary format that uses ASCII encoding, with a particular end-of-line standard which is different from that on Windows. We like to call this "plaintext", but it's really a misnomer for a very particular binary encoding standard. (Go back in time and find some sysadmin for an EDBDIC system and ask them what their definition of "plaintext file" is.) So you can't easily view and work with these files on a Windows system (just try opening one of these files in Notepad). Do we care about this? I don't know about you, but I don't; any Linux or Unix system can view Unix-standard text files just fine, and that's all that matters.
The same goes for cases where the file is gzipped; there isn't a Linux system from the last 20 years that doesn't have gzip installed. And on modern systems, xz is commonplace as well.
The only thing that matters is if your data, in whatever format it's in, is easily accessible and manipulatable. For those of us using Unix or Linux, there's various kinds of files which are: "plaintext" (ASCII/Unix EOL), gzipped, bzip2ed, even pkzipped, because these all have easily and universally-available tools to access this data: you can expect any modern Linux system to have these tools installed by default. As long as the tools to view and manipulate systemd logfiles are similarly prevalent (which they will be on any systemd distro, as long as they don't go changing the binary standard for these files), it'll be no different. No, you won't be able to easily copy these files to a Windows system and work with them there (without installing extra tools), but that's no different from today (and why would you want to do that anyway?).
Instead of copying my post about this very thing elsewhere, I'll just link it here:
http://linux.slashdot.org/comm...
I really think this plaintext logfile business is overblown.
>You get tools to do some more sophisticated things to log files, but if you find yourself with the data in a place without ready access to those tools, you will be out of luck.
As long as the logfiles are standardized, this shouldn't be a problem. Do I worry if I need to look at a .zip file or a .tar.gz or .tar.bz2 file? Of course not, because any Linux system has the tools available to view these archives. The only real problem is if I want to view something like a .tar.gz on a Windows system, but even viewing and editing text files is problematic on Windows since it uses a different line-ending standard than Unix and Linux systems, so you can't even claim that those plaintext logfiles can be viewed anywhere. Try opening plaintext logfiles in Windows Notepad and see what happens. Or try grepping that logfile for some string; oh right, you can't, because Windows doesn't have grep. You're just used to plaintext logfiles because Linux systems all have lots of tools useful for viewing those files and extracting data from them. When Linux systems all (or mostly) have systemd, they'll have the tools useful for viewing systemd logfiles as well.
Imagine if some Linux distro had plaintext logfiles, but they were all gzipped. Would you be complaining about that? How trivial is it to extract data from logfile.gz? Using tools like zgrep, zcat, or regular piping and redirection, it's trivial. It shouldn't (in theory) be any different with systemd logfiles; just use the appropriate tool to extract data in textual form (this tool probably has options to perform useful filtering on the data), and then you can pipe this into something else to process it further.
It seems like the algorithm could be tweaked a little so that if the GPS is showing the car in a river, a forest, a building, etc. instead of driving on a road as DR indicates, then DR should be favored. After all, it simply doesn't make any sense for the vehicle to be in a river. Or, if you're taking an exit ramp, and the GPS signals show the vehicle veering off into the trees while DR just shows the vehicle is proceeding around the curve at a normal rate, then it should be pretty obvious that the vehicle has not, in fact, gone off-road and is driving through metal barriers and trees at 40mph.
So how do you filter out all the extra accelerations from the users dropping the phone on the floor, fiddling with it, moving it around, etc. while the car is in motion? Phones aren't rigidly mounted in cars.
And considering how often Google Maps thinks I've instantly teleported to different places while driving, it doesn't look like all this theory really holds up in reality.
Surely you can use both, even if your DR data is not so great; just use the DR data to verify the GPS data makes sense. If the GPS signals say the vehicle has suddenly teleported into a river, check that against the DR. If the DR data says you're still driving straight, then disregard the GPS data until it agrees with the DR data.
Yeah, exactly. Just all the noise they'd generate from being handled by humans would be too much. Maybe if the phone was rigidly mounted in the car.
You don't even need to go to all that trouble. That kind of accuracy simply isn't necessary in a car as long as it has GPS. Dead-reckoning, in an in-car navigation system, is only needed to make up for the inaccuracy with GPS, which is mainly because you sometimes lose the signals (inside a parking garage, around too many tall buildings, etc.). You don't normally lose GPS signals for a very long amount of time, only short periods. So DR is just a supplement, and the vehicle's odometer signal alone is enough for supplementation, and an electronic compass signal is even better because this gives you direction, in case you turn the car while your GPS signal is missing. You're not looking for accuracy to the inch or even the foot, 50-foot accuracy is good enough in this application, so compensating for tire pressure is entirely unnecessary; they don't do that for the vehicle's odometer after all. You just need the system to warn you in enough time for you to make the next turn.
Android phones have had the ability to use dead reckoning for years now too.
Citation needed. This sounds like bullshit. You get dead reckoning by connecting to some sort of feedback device, namely the wheel sensors or odometer in the vehicle. Android phones don't have a connection to your car's computer; they work entirely off of GPS signals. In-car nav systems aren't like this; they use both GPS and dead-reckoning to get better accuracy than GPS alone (watch what happens when you drive into a parking garage with a GPS-only device). The problem with in-car nav systems is that they usually have very out-of-date technology otherwise, the maps aren't updated, you have to pay a fortune for updated maps, etc.
1 picture is worth 1000 words. However, the words one person thinks of when they see a picture will be different from the words another person thinks of seeing the same picture. Text is less ambiguous. And text in purely logical languages (like programming languages) is completely unambiguous. When you want exact, deterministic behavior, you need to express yourself in an unambiguous manner.
I just looked at a Dodge that was made in either Indiana or Illinois, I forget which. The American content was around 60-70% (the big exception was the transmission, which came from Korea). No significant part came from China. I think you're making things up.
Intel is not overseas, that's a blatant lie. Most of their fabs are in the US, mainly Oregon and Arizona. They have two 14nm fabs in Oregon and Ireland, 22nm fabs in Oregon, Arizona, and Israel, and their latest fab (14nm 450mm) is being built in Arizona. See here: http://en.wikipedia.org/wiki/L...
The Model F was better, at least for the keyswitch mechanism. They layout was awful though. The keyboard with the best layout is the Sun Type 5 (but the keyswitch mechanism there sucks).
I can name a bunch of things we manufacture here:
- aircraft carriers
- fighter jets (F-22, F-35)
- rifles (M-4)
- helicopters (Black Hawk, Apache)
Of course, all this stuff is purchased by the US government, using printed money. If you're looking for stuff that isn't solely for the defense sector, I can only think of a couple of things: Intel CPUs and Boeing passenger jets, along with some automobiles (I think Chryslers are still mostly made in the US).
Rational? Are you kidding? ClearCase is an utter abomination.
Contractors also cost a lot more, doubly so when you factor in that you have to keep paying them well past the end of the contract to fix all the screwups.
Yes, but which costs more, over the long term: hiring contractors with these problems, or hiring regular employees who are nearly impossible to get rid of when they're either no longer needed or don't perform?
Right now we have to wait a bit and see if they actually start fixing stuff, which Timothy just tried to convince us about. They cannot add the new code overnight.
They don't need to add any new code, they just need to delete all the Beta code.
Yep, Slashdot is on its last legs. If you're interested in true nerd stuff, you need to go to Reddit, and find particular forums (subreddits) there that you're interested in and subscribe to those. This segregation is something that Slashdot never did very well; it tried to have ways of allowing users to filter the news by category, but it never worked very well. On Reddit, everything's in a different forum, so it's segregated naturally. If you want to read Linux-related stuff, simply go to /r/Linux. If you want to read Microsoft-related crap, just go to /r/Microsoft. If you don't want to read MS-related crap and comments from MS fanboys, then don't go to that subreddit. Of course, this doesn't keep shills from invading /r/Linux, but at least you won't see articles about some stupid new MS product you don't care about. And there's lots of even more highly-focused subreddits, like /r/DDWRT if you're interested in DD-WRT, /r/kernel if you're interested in Linux kernel news, /r/linux_devices for that kind of thing, /r/embeddedlinux for linux on embedded devices, etc. I'm sure there's all kinds of other subreddits for other fields if you're interested or a fan of something, whether it's Apple, Mac, iOS, Blackberry, Android, Google, Oracle, whatever.
I'm pretty close to New England now, and this place seems to love authoritarianism. It's not very liberal at all (they think they're liberal because they tend to vote Democrat, but loving unions does not make you a liberal), the level of corruption is insane, and they have military soldiers with M-16s performing police duties.
I do advocate a break-up, but I think realistically if it does happen, it's going to take a long time, and things will have to get a LOT worse. America still has a lot of imperial power and inertia. Look how long it took the Roman empire to collapse; America's a lot more cohesive than that was (or other empires were); it's actually one single very large country (with some tiny territories, and a lot of military bases scattered about), rather than a small country with a huge amount of possessions where people had totally different languages and cultures.
Instead of spending the rest of my adult working years living through the decline, it seems like it'd be better to move to greener pastures.
I've totally missed the pro-Putin anti-gay stuff, but I guess I shouldn't be surprised. Holy crap I need to get out of this country. Pretty soon we're going to have another Victorian era, only worse. At least in Victorian times people knew how to act polite usually.
Obviously the 50s were a rather primitive time in computing, but I suspect much of the problem was that people at that time just weren't used to writing software, since it was so new. In the 80s, all kinds of stuff was written in assembly language, and it was far more complex than 100 instructions; just look at any of the console games of the era (NES, etc.), programs written for the popular microcomputers at the time (C=64, Apple ][), etc. All that stuff (the high-performance stuff at least) was written in 100% assembly.
Also, going back to the 60s, that was the era of the MULTICS system, as well as UNIX. MULTICS had a lot of features that are still considered high-end today, like being able to hot-swap CPUs and memory. Read more here.. It sounds to me like maybe there was a big divide between the extremely competent engineers of the time (Kernighan, Ritchie, etc.) who designed these systems and the low-level programmers who wrote stuff like payroll calculation programs. It probably didn't help that they hadn't yet developed decent debugging tools, plus for a while a lot of output was done with teletype terminals onto paper rather than with CRT monitors which of course massively slowed down the development and debugging processes.
Anyway, I'm not saying everyone today is incompetent compared to the people of the past, but for many things, it sure does seem like people have gotten less competent at actually producing anything. Are today's aerospace engineers really that incompetent compared to the engineers who built the B-52? Or, more likely, are our organizations more incompetent at managing people and producing results in a decent timeframe? Not everything is dog-slow; Apple seems to have no trouble turning out new products at a fast clip, and CPU manufacturers have done an impressive job of pushing the state-of-the-art over the last 20 years, though they've run into some problems with basic physics lately, but even so are still making impressive gains in MIPS/Watt efficiency, low-power modes, etc. The automotive industry seems to be making some decent gains with engine efficiency lately (I'm seeing mid-size SUVs now exceeding 30mpg), but they went through a period (70s-90s) where the American automakers were producing ridiculously bad cars. The aviation industry is a complete disaster, with companies taking decades to build new planes, and still having embarrassing problems with them. Parts of the software industry aren't doing so hot either; what has Microsoft done lately of note? Produced a re-skinned version of Win7 (which isn't really that much different from XP, almost 15 years old now) which doesn't add any significant new features but has a horrible new UI in a misguided attempt to unify desktop and mobile computing. And it's not just them; UIs all over have gotten worse because of this same trend.
Sounds like we Americans are in good company!
One big problem I see here is the conflation of "IT", "engineering", and "programming". Some of these things do overlap, but not nearly as much as people think they do. A job which involves being on-call does not involve programming; that kind of job is IT support, and probably is what's called a "systems administration" job, or just plain "IT support", or "helpdesk". People who do these jobs do not do 8 hours of programming a day; systems admins might do a little scripting, and that's about it, if they're lucky. The guy you call to help you reset your Active Directory password does not do programming, at all. The people who do programming as a full-time job are not on-call.
If you're a patient, you might want to consider seeking out female surgeons instead of male ones. Not only are women typically considered to have better fine-motor skills than men, if they don't work crazy hours, they're much less likely to fuck up while they've got you cut open and are messing around with a scalpel inside your body. Why the hell would I want some overworked, over-caffeinated person operating on me? That's a recipe for disaster.
8 hours a day at a computer? Gosh, that sounds like most white collar jobs of the last few decades.
Sounds like most non-managerial white collar jobs. The managerial jobs involve sitting in meetings all day long, and for the periods of time where computers are used, they involve printing out every single email and walking back and forth to the printer to get these emails.