Fucking retard can't spell. I stopped reading right there.
That's a losing battle like chiding people for using "less" instead of "fewer" or "which" when "that" would be more appropriate. You're outnumbered and outgunned and might as well go along with the trend and pry the apostrophe key off your keyboard.
"Workers in Tokyo spend an average of 2 hours per day commuting."
Assuming that things haven't changed since I lived in Tokyo many, many years ago, that's because:
1. Housing of any sort in Tokyo itself is very expensive. 2. Japanese employers pay transportation costs for workers.
At least on a train to the distant suburbs of Tokyo, you can sleep. And many Japanese do exactly that. How do they wake up when the train gets to their station? Damned if I know. But they do.
USB port? Probably not. Or if there is one, it's likely buried in the back of the unit and uses some weird mil-std connector. Not that there's no risk of compromise during maintenance, but probably nowhere near the situation with commercial hardware.
Mostly because the military doesn't need or want the latest fad. They need reliability. They have more than sufficient problems executing their missions without constantly changing interfaces and such "features" as automatic software updates made at a time convenient to the vendor.
Also, much military hardware is custom stuff built for a single purpose. The CPUs and OSes (if any) would be selected initially to have sufficient capability for their job, and usually not much more. If they do what's needed, what point would there be in upgrading? And why would you risk it? If you do it routinely, you'll probably make mistakes with serious consequences.
The last military contract I worked on -- a number of decades ago -- was a system that ran on a computer built to military standards using discrete transistors -- none of those fancy IC things. It was nowhere near as powerful as the PC-XTs in our office. But it would run equally poorly in the Arctic in January or the Middle East in July. And the computer would probably survive being inadvertently dropped off a truck by some high school dropout then run over by the next two vehicles in the convoy.
Frankly, the notion of having my life and safety depend on an NT based OS from Microsoft would not make me feel vary secure. Unix, compiled with only what is needed, would be better. But only if the system underwent a LOT of rigorous testing prior to deployment and wasn't upgraded unless the change were absolutely necessary.
There's a lot of truth in Arthur Clarke's short story "Superiority" http://www.mayofamily.com/RLM/... Folks who haven't read it, should.
"Why would the beacons be limited to MS-products reading MS Office documents?"
I'd assume the beacons use some sort of macro that's unique to MS products or that works differently in their free software equivalents -- like maybe asking permission before phoning home.
That's the trouble with being a spook. All those persnickety details one has to worry about.
Not a dumb idea at all. Probably in a couple of decades batteries will be good enough to dispense with the track electrification. It'll probably take that long for the CARB, NTHB, EPA, etc, etc, to hold hearings, promulgate standards, run tests., dictate updated standards, issue the necessary permits, etc to allow your little cars to be actually be built.
Trains work fine in Tokyo, London, etc. And even in the US in Boston and NYC which have decent if elderly public transportation. LA is a different story. Its marginal public transportation pretty much vanished after 1950.
But I have to have serious doubts about the economics of Musk's scheme. Even with relatively small diameter tunnels (a bit under 4 meters for the one in Musk's parking lot) it's going to be expensive. And it has to avoid a century's worth of infrastructure pockets of natural gas, and who knows what else.
Maybe it's workable... maybe...
I suspect that abandoning LA and moving the population someplace East of Barstow where there ain't no ten commandments and a man can raise a thirst would be cheaper.
"Of course then... then we get to JCL... If you don't know what that is, imagine a scripting language in which spaces matter..."
That would be bash -- or any other Unix shell script. However, I have to say that even at its most perverse, bash doesn't begin to approach JCL for pointless peculiarity. e.g. IEFBR14
Once, many, many years ago, I had to look at some COBOL software to see how it was handling some data. Remarkably easy to read and I'd never seen the language before or since.
I don't think I'd have the patience to program in COBOL
But I have to say that if I were an IT manager responsible for hundreds of thousands of lines of that stuff that worked, I'd probably be REALLY reticent to scrap it in favor of something more "modern".
Just trying to point out that in many cases a simple firewall is going to block everything. (or maybe nothing). Either way it's more or less a waste of time and money. I would assume that anyone savvy enough to know they are sending out way more traffic than they should would have considered and rejected a firewall appliance within the first 10 minutes after deciding that they have a problem.
Or you could save $35 and some labor costs by just unplugging the telephone company's data line. If you're willing to wait a while, don't pay the telco, and they'll unplug it for you.
BTW, I haven't tried it personally. But I suspect that if the mystery traffic is on port 443 (HTTPS) and is intermixed with legitimate traffic, the Raspberry Pi may have some trouble distinguishing real from bogus. And we're all supposed to use HTTPS because it's secure, right?
"It's almost certainly a hell of a lot easier to build a self-driving flying car than it is to build a self driving regular car."
Sadly, probably not so. A "flying car" of the type most people imagine has to be able to deal with congestion and probably traffic control -- in three dimensions. Imagine thousands of these things trying to exit parking lots around a stadium more or less simultaneously after a sporting event or rock concert -- without running into each other, pre-existing air traffic, power lines, buildings, drones, the Goodyear blimp and lord knows what else -- all with wind blowing a half gale and sleet or snow whipping around. The only things that could make it worse would be a few police air traffic control vehicles misdirecting traffic and some vehicles in the mix running some version of Windows that has decided that this is a dandy time to upgrade the OS.
"The problem with flying cars, is that they will not be able to compete with Hyperloop."
Hyperloop hardware is probably doable. But with costs for serious transportation tunnels in urban areas running well over $1,000,000,000 per mile. (Boston's Big Dig, Seattle's Alaskan Way Viaduct) I'm not sure hyperloop will ever get off (OK, OK, under...) the ground.
Failsafe computer software to control Personal Air Vehicles probably isn't impossible. But we couldn't write it today.
My guess. Maybe 30 years for the requisite software and sensors. The airframe hardware, legal, liability, and security issues might take longer than that.... If we started on them today.... Which we won't.
Maybe. But in my experience, Excel spreadsheets tend to be slow, clunky and, most annoying, very buggy. I don't think those are admirable characteristics. Nor do I think those problems are essential to the FP paradigm.
AFAICS, the principle value of non-trivial spreadsheets is the ability Excel, Oocalc, etc to generate pretty graphs for presentation purposes with less aggravation than other alternatives. And, I guess maybe under some circumstances a spreadsheet is a viable alternative to a small database.
I know squat about Functional Programming. But I'm told that Python's List (and generator) comprehensions are a functional programming concept. Input a list, perform an operation on all or part, and output an altered list. Not terribly readable IMO, but otherwise quite likeable. I find myself using them quite a lot.
As for stuff like closures. The explanations I've read tend to be utterly opaque. Sort of like a color-blind individual trying to explain the color green. I'm not sure if the problem is me or the explainers. After a lot of reading, I think I sort of might understand how closures be done in Python. But it's sort of like reading about how to build a working mechanical arm out of toothpicks. Interesting, but I'll be damned if I can envision a situation where I might want to do that.
"You can't tell whether the results are correct in any more than trivial cases."
In most cases, I think you can safely assume that non-trivial results are probably mostly wrong. Coding a spreadsheet correctly is no easier than coding the same logic in FORTRAN, Python, or any other relatively sane programming language. Which is to say -- it's damn difficult.
Slashdot Mirror
"Its"
Fucking retard can't spell. I stopped reading right there.
That's a losing battle like chiding people for using "less" instead of "fewer" or "which" when "that" would be more appropriate. You're outnumbered and outgunned and might as well go along with the trend and pry the apostrophe key off your keyboard.
Don't listen to HIM. He's a charlatan. I can do everything he claims he can do in 10-20 years in two years. Give ME all your money!
"Okay. The more efficient, more politically expedient approach is to level the majority of the LA metro area and start over from scratch?"
That idea has much to recommend it. But, I imagine that were it attempted, the result would be something even worse -- assuming that's possible.
"Workers in Tokyo spend an average of 2 hours per day commuting."
Assuming that things haven't changed since I lived in Tokyo many, many years ago, that's because:
1. Housing of any sort in Tokyo itself is very expensive.
2. Japanese employers pay transportation costs for workers.
At least on a train to the distant suburbs of Tokyo, you can sleep. And many Japanese do exactly that. How do they wake up when the train gets to their station? Damned if I know. But they do.
USB port? Probably not. Or if there is one, it's likely buried in the back of the unit and uses some weird mil-std connector. Not that there's no risk of compromise during maintenance, but probably nowhere near the situation with commercial hardware.
Mostly because the military doesn't need or want the latest fad. They need reliability. They have more than sufficient problems executing their missions without constantly changing interfaces and such "features" as automatic software updates made at a time convenient to the vendor.
Also, much military hardware is custom stuff built for a single purpose. The CPUs and OSes (if any) would be selected initially to have sufficient capability for their job, and usually not much more. If they do what's needed, what point would there be in upgrading? And why would you risk it? If you do it routinely, you'll probably make mistakes with serious consequences.
The last military contract I worked on -- a number of decades ago -- was a system that ran on a computer built to military standards using discrete transistors -- none of those fancy IC things. It was nowhere near as powerful as the PC-XTs in our office. But it would run equally poorly in the Arctic in January or the Middle East in July. And the computer would probably survive being inadvertently dropped off a truck by some high school dropout then run over by the next two vehicles in the convoy.
Frankly, the notion of having my life and safety depend on an NT based OS from Microsoft would not make me feel vary secure. Unix, compiled with only what is needed, would be better. But only if the system underwent a LOT of rigorous testing prior to deployment and wasn't upgraded unless the change were absolutely necessary.
There's a lot of truth in Arthur Clarke's short story "Superiority" http://www.mayofamily.com/RLM/... Folks who haven't read it, should.
"Why would the beacons be limited to MS-products reading MS Office documents?"
I'd assume the beacons use some sort of macro that's unique to MS products or that works differently in their free software equivalents -- like maybe asking permission before phoning home.
That's the trouble with being a spook. All those persnickety details one has to worry about.
"Gee, what would you do?"
Move?
Not a dumb idea at all. Probably in a couple of decades batteries will be good enough to dispense with the track electrification. It'll probably take that long for the CARB, NTHB, EPA, etc, etc, to hold hearings, promulgate standards, run tests., dictate updated standards, issue the necessary permits, etc to allow your little cars to be actually be built.
"Or, LA could redesign itself into a proper livable city instead of the horrible suburban ghetto that it is."
You want to pave paradise, put up a parking lot?
Trains work fine in Tokyo, London, etc. And even in the US in Boston and NYC which have decent if elderly public transportation. LA is a different story. Its marginal public transportation pretty much vanished after 1950.
But I have to have serious doubts about the economics of Musk's scheme. Even with relatively small diameter tunnels (a bit under 4 meters for the one in Musk's parking lot) it's going to be expensive. And it has to avoid a century's worth of infrastructure pockets of natural gas, and who knows what else.
Maybe it's workable ... maybe ...
I suspect that abandoning LA and moving the population someplace East of Barstow where there ain't no ten commandments and a man can raise a thirst would be cheaper.
"Of course then ... then we get to JCL ... If you don't know what that is, imagine a scripting language in which spaces matter ..."
That would be bash -- or any other Unix shell script. However, I have to say that even at its most perverse, bash doesn't begin to approach JCL for pointless peculiarity. e.g. IEFBR14
Why is that a surprise? If people could master COBOL 50 years ago, why would they not be able to master it today?
Once, many, many years ago, I had to look at some COBOL software to see how it was handling some data. Remarkably easy to read and I'd never seen the language before or since.
I don't think I'd have the patience to program in COBOL
But I have to say that if I were an IT manager responsible for hundreds of thousands of lines of that stuff that worked, I'd probably be REALLY reticent to scrap it in favor of something more "modern".
Just trying to point out that in many cases a simple firewall is going to block everything. (or maybe nothing). Either way it's more or less a waste of time and money. I would assume that anyone savvy enough to know they are sending out way more traffic than they should would have considered and rejected a firewall appliance within the first 10 minutes after deciding that they have a problem.
"You know that you are old ..."
Hell, man. I AM old. Heck, I can remember when they told me that I should switch to NT based Windows because it was much more secure than Windows 98.
Or you could save $35 and some labor costs by just unplugging the telephone company's data line. If you're willing to wait a while, don't pay the telco, and they'll unplug it for you.
BTW, I haven't tried it personally. But I suspect that if the mystery traffic is on port 443 (HTTPS) and is intermixed with legitimate traffic, the Raspberry Pi may have some trouble distinguishing real from bogus. And we're all supposed to use HTTPS because it's secure, right?
"It's almost certainly a hell of a lot easier to build a self-driving flying car than it is to build a self driving regular car."
Sadly, probably not so. A "flying car" of the type most people imagine has to be able to deal with congestion and probably traffic control -- in three dimensions. Imagine thousands of these things trying to exit parking lots around a stadium more or less simultaneously after a sporting event or rock concert -- without running into each other, pre-existing air traffic, power lines, buildings, drones, the Goodyear blimp and lord knows what else -- all with wind blowing a half gale and sleet or snow whipping around. The only things that could make it worse would be a few police air traffic control vehicles misdirecting traffic and some vehicles in the mix running some version of Windows that has decided that this is a dandy time to upgrade the OS.
"The problem with flying cars, is that they will not be able to compete with Hyperloop."
Hyperloop hardware is probably doable. But with costs for serious transportation tunnels in urban areas running well over $1,000,000,000 per mile. (Boston's Big Dig, Seattle's Alaskan Way Viaduct) I'm not sure hyperloop will ever get off (OK, OK, under ...) the ground.
Failsafe computer software to control Personal Air Vehicles probably isn't impossible. But we couldn't write it today.
My guess. Maybe 30 years for the requisite software and sensors. The airframe hardware, legal, liability, and security issues might take longer than that. ... If we started on them today. ... Which we won't.
Maybe. But in my experience, Excel spreadsheets tend to be slow, clunky and, most annoying, very buggy. I don't think those are admirable characteristics. Nor do I think those problems are essential to the FP paradigm.
AFAICS, the principle value of non-trivial spreadsheets is the ability Excel, Oocalc, etc to generate pretty graphs for presentation purposes with less aggravation than other alternatives. And, I guess maybe under some circumstances a spreadsheet is a viable alternative to a small database.
Here's a document that explains functional concepts in Python. Seems reasonable:to me.
https://docs.python.org/2/howt...
"The world's most popular programming language (Excel) is functional"
Is that intended to be an argument in FAVOR of FP?
I know squat about Functional Programming. But I'm told that Python's List (and generator) comprehensions are a functional programming concept. Input a list, perform an operation on all or part, and output an altered list. Not terribly readable IMO, but otherwise quite likeable. I find myself using them quite a lot.
As for stuff like closures. The explanations I've read tend to be utterly opaque. Sort of like a color-blind individual trying to explain the color green. I'm not sure if the problem is me or the explainers. After a lot of reading, I think I sort of might understand how closures be done in Python. But it's sort of like reading about how to build a working mechanical arm out of toothpicks. Interesting, but I'll be damned if I can envision a situation where I might want to do that.
"You can't tell whether the results are correct in any more than trivial cases."
In most cases, I think you can safely assume that non-trivial results are probably mostly wrong. Coding a spreadsheet correctly is no easier than coding the same logic in FORTRAN, Python, or any other relatively sane programming language. Which is to say -- it's damn difficult.