Statistically, that "cow" (ground beef) would be from ~200 cows. Sausage could be as few as one, but much more likely to be just as "processed" as the cow. Ham or Canadian Bacon might be from a single animal, but I seriously doubt Dominion's uses anything from the "quality" side of the market. The chicken is the only thing likely to have been from a single chicken -- unless they used "McNuggets", which is entirely possible. ("mechanically separated" is the term used.)
(There are some "how it's made" shows that shouldn't be watched.)
If this is like the upgrade I've seen, the ENTIRE STATION is down for the duration of the updates. The back office systems, credit card readers, EVERYTHING is down for updates and/or replacement. And the software is such a work of art, if any single piece doesn't work, you have to rollback the universe.
I have a friend who did this for a while (I still have the laptop with all the oddball software on it.) He's thinking he'd like to get a site done in one night instead of 2+. This is not something that is done like a 9-5 job. It's done more like midnight to 4-5am. And there's no wiggle room for screwing shit up: the station MUST open in the morning.
Fiber: 100km (~62mi) per hop, with a practically zero (femtosecond) latency optical regen, subject to physical breaks (idiot copper thieves, backhoes, trail derailments, etc.) Microwave: 25mi per hop [limited by tower height and curvature of the Earth], with microsecond repeaters, subject to atmospheric disruption and misalignment
Last I read, microwave didn't do 100Gbps. Nor is it cheap to transmit many parallel streams. DWDM has been common in the optical space for decades.
You do realize a "mode conditioning cable" is for launching a single-mode laser into a multi-mode cable; that's a mixed-mode use, and only works because most SM optics (LX, ZX) have higher output power and much higher receive sensitivity. You're using optics rated to 10km (or more) and getting 1/16th that range out of them.
Standard "SX" hardware simply doesn't have the power or sensitivity to work over km distances.
And yet, the two existing fiber deployments in NC (Wilson and Salisbury) prove the exact opposite. And in fact, most "big business" have their ways around zoning, permitting, taxation, etc.
Those that fail do so for two reasons: 1) the incumbents drag them through enough legal bullshit they're out of money before they can buy any fiber, much less string any. 2) the all too common mismanagement found within any government project burns through mountains of cash, and then their business model is to burn even more. LUS and MI-Connection are good examples of #2 -- I don't know how much was spent building LUS or buying up the bankrupt Adelphia plant, but their plans for revenue were unrealistic. What I recall of UTOPIA puts them in both camps.
In that the only mailbox you have in your front yard is the one for the USPS, yes. However, there are private companies providing mailboxes -- 'tho they use the USPS instead of their own courier(s).
Given the cost of the non-USPS couriers (Fedex, etc.) and the fact the USPS loses money day after day, I don't see anyone stepping up to replace the USPS.
the FBI inspected the SEBs around the seat he occupied on his 4/15 Denver to Chicago leg
Did they seize the aircraft immediately after his flight? I doubt it. So a) the damage may have been pre-existing; they didn't look until after his flight. b) the damage could have happened well after his flight. And finally, c) NONE of this proves, in any way, WHO (or what) caused the damage.
It certainly is "still necessary". However, processors have gotten fast enough that people don't notice how horrible their OS and applications actually are. Compilers (read: gcc) have gotten *worse*, not better because there are so few people who really understand assembly, or the complexities of modern processors.
Actually, you can, but it's certainly a lot more work. But then, porting AN OS to a different processor usually involves more work than changing the -march option to gcc. (i.e. coding to handle a completely different platform. It's not like you can pop the i7 out of your desktop and replace it with an ARM or MIPS processor.)
Personally, I do something very similar... every address block assigned to APNIC. Yes, it's a shotgun approach, but it's surprisingly effective. HOWEVER, it's not something that can be done by everyone; it works for me because I have no need to talk to anything in Asia. That won't work for my employer as they have offices all over the world -- including Asia, and all of our manufacturing is done by companies in Asia.
The current 40 year old fleet of US reactors? Those wouldn't last a week before some alarm trips and it automatically shuts down because the operators aren't present to deal with it. (relatively minor events happen all the time, and while they are highly automated (honestly, there are many places humans don't want to go), they aren't 100% autonomous.)
A "modern" helium pebble-bed reactor, would fair better, but something would eventually trip it, too, without any operators present.
In theory, a reactor has the fuel to run for years. But as many such sci-fi shows point out, without load from the grid, they'll automatically shutdown.
That would be true of satellites as well... if they don't recharge everyday (solar), they'll be dead in short order.
Our long range space probes (voyager, etc.) have already won this contest. They've been running for decades off their RTG, well out of range to be solar powered.
Hmm... cleaning staff walks off with a phone running a GPS tracker. Gee, how hard is it to tell a) who was in the office when it left the desk, and b) where the fuck it when from there?
(I've never understood the logic of stealing cellphones. A device identifiable and trackable by it's very design.)
It's a cellphone. Wrapping it in foil means it won't function as anything. You'd be better off a) turning it off, or b) leaving it on your desk (at the office or your home.) If you are "on call" then you are technically working, so that phone needs to be 100% functional and they have the right to track it. If you don't like being tracked on the job, then find a different job.
You've completely missed the weakness of those initscript function library dependencies. In the handful of debian specific scripts I checked, all of them use at most 2 functions. They are all distro managed scripts, so it's not a surprise they all want to use "daemon" -- the most trivial shit in the world to remove.
The issue with systemd is not in how it starts or stops tasks. It is entirely with it's size, complexity, and the cancer-like scope creep of taking over tasks that aren't "starting and stopping" other subsystems.
Yes, rcS generally is just a stub to call "rc S", but not in all configurations, which is why inittab isn't: "si::sysinit:/etc/init.d/rc S"
Startup order dependency was "fixed" (for various definitions) by update-rc.d and language in the initscript header, like a thousand years ago. It's not perfect, but it does work. And for servers, a 100% predictable, repeatable, deterministic boot sequence trumps the 1.28s speed boost from the likes of upstart and systemd. For desktops, speed and flexibility are important, but troubleshooting a "random" boot order is a pain in the ass. (even moreso when upstart/systemd is eating all console output "for logging purposes")
./foo start and./foo stop, perhaps??? An initscript is just a shell script. 90% of the initscripts I've written will work anywhere you have a somewhat smart/bin/sh. (the other 10% are targeted to specific distro's and will include shit specific to that distro, ugly, but that's what it takes.)
Plus/etc/rc.d contains/etc/rc.d/rc?.d directories, so the total is ~8x too many... 192 vs. 26 *actual* scripts on my machine. Looking at those 26 scripts, most of them use only 1 or 2 functions defined in the "library", and most don't need a library function for the task.
Only because inittab (what the traditional init does) lists rcS and rc as tasks. Change that and it can run anything you damn well please.
systemD... good luck purging that, as many other parts of the system are becoming dependent on it in increasingly complex ways. (for another really good example... plymouth in ubuntu.)
Slashdot Mirror
Statistically, that "cow" (ground beef) would be from ~200 cows. Sausage could be as few as one, but much more likely to be just as "processed" as the cow. Ham or Canadian Bacon might be from a single animal, but I seriously doubt Dominion's uses anything from the "quality" side of the market. The chicken is the only thing likely to have been from a single chicken -- unless they used "McNuggets", which is entirely possible. ("mechanically separated" is the term used.)
(There are some "how it's made" shows that shouldn't be watched.)
If this is like the upgrade I've seen, the ENTIRE STATION is down for the duration of the updates. The back office systems, credit card readers, EVERYTHING is down for updates and/or replacement. And the software is such a work of art, if any single piece doesn't work, you have to rollback the universe.
I have a friend who did this for a while (I still have the laptop with all the oddball software on it.) He's thinking he'd like to get a site done in one night instead of 2+. This is not something that is done like a 9-5 job. It's done more like midnight to 4-5am. And there's no wiggle room for screwing shit up: the station MUST open in the morning.
Fiber: 100km (~62mi) per hop, with a practically zero (femtosecond) latency optical regen, subject to physical breaks (idiot copper thieves, backhoes, trail derailments, etc.)
Microwave: 25mi per hop [limited by tower height and curvature of the Earth], with microsecond repeaters, subject to atmospheric disruption and misalignment
Last I read, microwave didn't do 100Gbps. Nor is it cheap to transmit many parallel streams. DWDM has been common in the optical space for decades.
You do realize a "mode conditioning cable" is for launching a single-mode laser into a multi-mode cable; that's a mixed-mode use, and only works because most SM optics (LX, ZX) have higher output power and much higher receive sensitivity. You're using optics rated to 10km (or more) and getting 1/16th that range out of them.
Standard "SX" hardware simply doesn't have the power or sensitivity to work over km distances.
[See also: http://en.wikipedia.org/wiki/M...
And yet, the two existing fiber deployments in NC (Wilson and Salisbury) prove the exact opposite. And in fact, most "big business" have their ways around zoning, permitting, taxation, etc.
Those that fail do so for two reasons: 1) the incumbents drag them through enough legal bullshit they're out of money before they can buy any fiber, much less string any. 2) the all too common mismanagement found within any government project burns through mountains of cash, and then their business model is to burn even more. LUS and MI-Connection are good examples of #2 -- I don't know how much was spent building LUS or buying up the bankrupt Adelphia plant, but their plans for revenue were unrealistic. What I recall of UTOPIA puts them in both camps.
In that the only mailbox you have in your front yard is the one for the USPS, yes. However, there are private companies providing mailboxes -- 'tho they use the USPS instead of their own courier(s).
Given the cost of the non-USPS couriers (Fedex, etc.) and the fact the USPS loses money day after day, I don't see anyone stepping up to replace the USPS.
Did they seize the aircraft immediately after his flight? I doubt it. So a) the damage may have been pre-existing; they didn't look until after his flight. b) the damage could have happened well after his flight. And finally, c) NONE of this proves, in any way, WHO (or what) caused the damage.
It certainly is "still necessary". However, processors have gotten fast enough that people don't notice how horrible their OS and applications actually are. Compilers (read: gcc) have gotten *worse*, not better because there are so few people who really understand assembly, or the complexities of modern processors.
Actually, you can, but it's certainly a lot more work. But then, porting AN OS to a different processor usually involves more work than changing the -march option to gcc. (i.e. coding to handle a completely different platform. It's not like you can pop the i7 out of your desktop and replace it with an ARM or MIPS processor.)
Personally, I do something very similar... every address block assigned to APNIC. Yes, it's a shotgun approach, but it's surprisingly effective. HOWEVER, it's not something that can be done by everyone; it works for me because I have no need to talk to anything in Asia. That won't work for my employer as they have offices all over the world -- including Asia, and all of our manufacturing is done by companies in Asia.
"@aol.com" isn't worth shit. What AOL, Inc. owns, however, is far from trash.
That he/she has an email address is a very bad omen. (...!some!where!coboldude would be acceptable)
The odds of voyager getting hit by a space rock are about as good as you getting hit by one.
Actually, they build up on the intake and exhaust shafts. Eventually (years?) no water would make it through the plant.
The current 40 year old fleet of US reactors? Those wouldn't last a week before some alarm trips and it automatically shuts down because the operators aren't present to deal with it. (relatively minor events happen all the time, and while they are highly automated (honestly, there are many places humans don't want to go), they aren't 100% autonomous.)
A "modern" helium pebble-bed reactor, would fair better, but something would eventually trip it, too, without any operators present.
In theory, a reactor has the fuel to run for years. But as many such sci-fi shows point out, without load from the grid, they'll automatically shutdown.
That would be true of satellites as well... if they don't recharge everyday (solar), they'll be dead in short order.
Our long range space probes (voyager, etc.) have already won this contest. They've been running for decades off their RTG, well out of range to be solar powered.
Hmm... cleaning staff walks off with a phone running a GPS tracker. Gee, how hard is it to tell a) who was in the office when it left the desk, and b) where the fuck it when from there?
(I've never understood the logic of stealing cellphones. A device identifiable and trackable by it's very design.)
It's a cellphone. Wrapping it in foil means it won't function as anything. You'd be better off a) turning it off, or b) leaving it on your desk (at the office or your home.) If you are "on call" then you are technically working, so that phone needs to be 100% functional and they have the right to track it. If you don't like being tracked on the job, then find a different job.
Depends on the quality of the recordable optical media. In fact, the same is true of pressed CD/DVD/Bluray.
You've completely missed the weakness of those initscript function library dependencies. In the handful of debian specific scripts I checked, all of them use at most 2 functions. They are all distro managed scripts, so it's not a surprise they all want to use "daemon" -- the most trivial shit in the world to remove.
The issue with systemd is not in how it starts or stops tasks. It is entirely with it's size, complexity, and the cancer-like scope creep of taking over tasks that aren't "starting and stopping" other subsystems.
Yes, rcS generally is just a stub to call "rc S", but not in all configurations, which is why inittab isn't: "si::sysinit:/etc/init.d/rc S"
Startup order dependency was "fixed" (for various definitions) by update-rc.d and language in the initscript header, like a thousand years ago. It's not perfect, but it does work. And for servers, a 100% predictable, repeatable, deterministic boot sequence trumps the 1.28s speed boost from the likes of upstart and systemd. For desktops, speed and flexibility are important, but troubleshooting a "random" boot order is a pain in the ass. (even moreso when upstart/systemd is eating all console output "for logging purposes")
./foo start and ./foo stop, perhaps??? An initscript is just a shell script. 90% of the initscripts I've written will work anywhere you have a somewhat smart /bin/sh. (the other 10% are targeted to specific distro's and will include shit specific to that distro, ugly, but that's what it takes.)
Plus /etc/rc.d contains /etc/rc.d/rc?.d directories, so the total is ~8x too many... 192 vs. 26 *actual* scripts on my machine. Looking at those 26 scripts, most of them use only 1 or 2 functions defined in the "library", and most don't need a library function for the task.
Only because inittab (what the traditional init does) lists rcS and rc as tasks. Change that and it can run anything you damn well please.
systemD... good luck purging that, as many other parts of the system are becoming dependent on it in increasingly complex ways. (for another really good example... plymouth in ubuntu.)