MS-DOS never ran on an 8080, because MS-DOS didn't exist for the 8080, because the first IBM PC was based on a 4.77MHz 8088 and MS-DOS as we know it was not yet a thing until IBM approached Microsoft about an operating system for said IBM PC.
Meanwhile, an 8086 was a 16-bit CPU with a 16-bit bus, and the (somewhat later) 8088 was a 16-bit CPU with an 8-bit bus. They used the same (16-bit) instruction set.
tl;dr There has never been an 8-bit IBM PC, therefore there is no historical reason for 8-bit MS-DOS.
Competent UNIX admin? Let me submit that it's just not needed to be competent with UNIX: You just need some basic knowledge of the concept of a subnet, and it might help to know what a broadcast domain is.
Anyone who can configure a venerable WRT54GL with OpenWRT or Tomato or DD-WRT and isn't afraid of a 900MHz ISM-band Ubiquiti (or other) radio can do this.
It's just Ethernet frames that happen to encapsulate IP. No big deal.
I mean, FFS: A couple of years ago I built such a system. A wealthy customer was having a party, and was having circuit issues on the bonded T1s at his house (yep, really) and Really, Really wanted his Sonos system to be reliably online to stream music for his guests.
We sent his wife to the Verizon store, and she came back with an LTE Wifi hotspot. I set up a WRT54GL running Shibby's Tomato-USB as a wireless client put the LTE hotspot in a window where it had reasonable signal. We had another WRT54GL working as a wired client off of this (triple-NAT? so what), which in turn plugged into the Sonos mesh with some Cat5.
DHCP figured out the addressing automagically; all I needed to do was make sure that each WRT54GL was issuing a unique subnet so Linux's routing tables weren't confusing itself.
And....done. It was an ugly hack thrown together late on a Saturday with parts on-hand and it got the party going just fine.
Which is the same as, or perhaps slightly more complicated than, a ProxyHam setup.
Oh, and ProxyHam is easily traceable, too: I haven't actually had my hands on Ubiquiti's 900MHz gear, but their 2.4GHz 802.11N stuff has an excellent and honest spectrum analyzer built-in with the default firmware. I would be shocked and amazed if their 900MHz parts differed in this regard.
A $100 radio, some graph paper, a directional antenna, a working brain and some mobility is all you need to use to triangulate the "isolated" end of a ProxyHam/ProxyGambit connection that is actively being used down to at least the household that the signal emanates from.
Alternatively, any spectrum analyzer that covers whatever band it is that is used to backhaul to the user's location can be used to locate them fairly easily: You can try, but at the end of the day you can never hide while broadcasting with a radio -- especially since we've largely abandoned frequency-hopping spread-spectrum (which was actually rather hard to narrow down using traditional tools).
The functional difference between a microprocessor-controller washing machine and an electromechanically-controlled washing machine is insufficient to deem one robot, and the other not a robot.
In both cases, the use is the same: Dirty clothes go in. Time passes. Clean, damp clothes come out. Humans do the rest of the work, just as they have now for a very long time.
A modern front-load saves roughly zero human labor over a 60-year-old front-load.
The Macon-Bibb Fire Department gets 13 thousand calls per year and has to respond to all of them.
I don't see that number anywhere in the link you provided.
What I do see is that it has a population of 156,462, over 266 square miles. The FD has a budget of $25.6 million. None of that seems unreasonable.
13,000 fire calls, though? Detroit, Michigan is blatantly famous for its ongoing and recurrent structure fires with its population of ~688,000 [citation]. Even Detroit only sees 30,000 fire calls a year, of which 7,000 involve fires that are actually fought.[citation]
Give me a citation that actually supports your claim, or GTFO.
The first electric programmable computer was installed in 1943, and now there pretty ubiquitous. Give robots another decade and they'll catch up.
Or you could say they're already here. I have a robot which washes and drys my dishes, another that washes my clothes, two that make me ice. Several which play video content. One which opens and closes my garage door. Heck, they're everywhere.
You don't have robots to wash and dry your dishes, or your clothes. Or make ice. Or play videos. Or open or close your garage door.
You have a multitude of relatively dumb machines that do simple things: They spin and/or open and close valves, sometimes with a timer or a small number of sensors (turbidity, etc) to control when the valves open/close and which direction to spin the motor(s).
These dumb machines were doing most of these things way prior to 1943.
A robotic laundry machine will collect the clothes from a pile, sort them as a good housewife would, launder them as appropriate for the material and color, dry them automatically, sort them based on wearer, and stock them as household needs dictate. A good robotic dishwasher will take your stacks of dirty dishes, make them clean, dry them, and install them back in the cabinet where they belong.
These are things that aren't happening and aren't close to happening.
So why wait another decade for robots to catch up? What's special about that 10-year figure other than the fact that you pulled it directly out of your ass?
At very busy intersection a block from my house, drivers are presented with a green right-turn arrow at the same time as pedestrians are presented with a walk signal.
(Yes, I've almost been mowed down a few times because of a combination of this and Newtonian physics.)
And governments are perfectly capable of reigning in Google, as you can see from the fact that they can tap their private networks and force them to set up web portals (Google seems to be offering as much resistance as possible, through using encryption and notifications whenever they can).
It is a fact that if the NSA wants to put a magic box in your datacenter, you must accept their magic box into your datacenter and tell noone of its existence, under threat of treason (because terrorism).
Google's good use of HTTPS protects me from the casual middlemen, but it does not protect me from the government in a time of war (we've always been at war with Eastasia).
Me, too. I am consistently amazed at the quality and accuracy of Google Maps' traffic layer, which relies entirely upon location reporting. This data also feeds into both of Google's navigation systems (Waze and Maps).
I also use and appreciate Google's Location History, which I do use to track myself and generate accurate and accountable bills for my clients. This apparently works fine, because nobody has ever questioned any of my bills.
Now, that said: If I were up to no good, I'm also smart enough to leave the cell phone at home.
You agreed to the tracking before your phone even let you use it as a phone. You had the option to disagree. You chose differently than you might have preferred, but you still chose what you chose.
Didn't read the contract you agreed to? Cry me a fucking river. (I see that you've already begun doing that.)
Further, you don't even know what "root" means: It is nothing more than an abstraction of UID 0, and of course there are things running as UID 0. It's fucking Unix. PID 1 (aka init) is executed by the kernel with root (UID 0) privileges, and thereafter can do whatever it is programmed to do.
If you have an HTPC on your BFT, then why do you care? Just run Kodi or Plex or whatever and be done with it.
Me, I have plenty of old PCs around, but sadly none are up for modern HTPC duty.
I use casting to put my VPN-connected phone (which for all intents and purposes is now in the UK, because again VPN) into a state whereby I can watch the BBC freely. On the BFT. With a $23-$20(rebate-ish) Chromecast.
For all intents and purposes, local Chromecast traffic does not route. It relies on Ethernet broadcast to do its magic (whatever that Ethernet may consist of).
So, the Chromecast must be on the on the same logical LAN as the rest of your network. Can't/won't/don't want to do that? Learn some iptables magic or naff off (good luck!).
Every device in this field is similar in this behavior.
How about: Tab-casting and device-casting (whatever they are called)?
Whatever is on my phone/tablet/whatever, or on a Chrome tab on any manner of modern PC, I can send it to my BFT for the amusement (or profit, in a business setting) of others.
Does the Fire TV do that?
If so, Fire TV is a win because it includes a real UI and a remote. (Unless it is the Fire TV -stick-, and then things get murky before the discussion even starts.)
But if not, then.....sheesh. I expect that my cousins and aunts will be able to link to my Chromecast and show their vacation on the BFT, or that a bunch of drunken friends fighting over Youtube videos in a gathering and a great time will be had by all.
If Fire TV can't do these things, then Chromecast is very social. And Amazon's offerings are de-facto not.
An? I recognize that English can be tricky even for folks born in such countries, but sheeshL
Again: "an usb"?
Is there any pronunciation of USB that does elicits an "an"? Or have I been saying U S B wrong all of these years by spelling it out, and should be instead saying "uhsbah"?
Because Webster calls it \ËOEyü-(ËOE)es-ËbÄ"\, and I can't argue with that. (Fucking/. Unicode ruining linguistics yet again, but the link is good.)
Say it out-loud: "A USB," vs. "An USB.": (IE, "A yoo-ess-bee," vs "An yoo-ess-bee")
If the former still sounds more-wrong than the latter, then good luckl with my language!
This is wonderful. The Chromecast's 2.4GHz 802.11n tops out at 72Mbps -- barely better than 802.11g. And while it is begrudgingly slogging in that 72Mbps data, it also is hogging timeslots from devices that could be at ~150 or ~300Mbps if the channel weren't full.
I couldn't reliably stream HD video from the Chromecast app on my Samsung S5 to the Chromecast on 802.11g*. Frames were dropped frequently enough to be a real usability problem, and various disconnects happened enough to make it useless.
I expect that this new adapter will solve the problems with the device that I was experiencing. (Not that it owes me much: I paid $23, shipped, for it on Black Friday, and it came with $20 of Play Store credit that I surely would've used sooner or later anyway.)
*: Incidentally (yes, really incidental) I moved the wireless network that my Chromecast and my phone use from 802.11g to 2.4GHz 802.11n this very afternoon. The streaming of BBC iPlayer via a VPN got a lot better: It didn't freeze or outright stall. It's still a bit rough, though. The phone syncs at 144Mbps, and the Chromecast can't go more than 72. I'd love to say that bandwidth shouldn't be a problem in these modern enlightened times, but apparently it is.
**: As an unreferenced footnote, fixed devices such as Chromecast should always have a hardwired option. Every other*** fixed device on my network is hard-wired; why should the Chromecast not be? I've never carried the Chromecast between TVs, although it's easy enough to do so.
***: Except for the Wii, because that costs extra and its wireless burden is not all that burdensome.
****: The other option I was exploring today was setting up a dedicated access point just for the Chromecast. I've got the hardware, and a bit of room on the outskirts of the ISM band, but fuuuuuu.
Which, all told, is still a pain in the ass, I guess:
The OG Droid's rooting process involved using adb to put a special su binary on the device...and, done.
My next two phones (Droid 4, Droid Bionic) both suffered from needing Safestrap and various fuckery to do anything fun.
And now I have an S5, which adds a downgrade to that process. But at least Samsung devices have odin, though, for when everything goes tits-up: Permanently bricking is all but impossible.
There may be a directly-odin flashable way; I don't know. It sure seems like there ought to be; Google it, cunt.;)
The waters here are murky for me because I'm on Verizon, so I'm blessed with a locked bootloader and therefore none of the cool kids like to play with me. If it were unlocked, I'd probably just install cyanogenmod and call it done.
But the downgrade, as I understand it, is needed because towelroot is needed because, well, it's VZW. And the security exploit that towelroot uses (thanks, geohot!) got fixed a few short months into the S5's life.
The downgrade is also needed because safestrap is awesome (thanks, Hashcode!), but won't run on newer kernels: It still does its thing, with multiple ROM slots and magical flashing of zip files, but its GUI becomes borked.
This can allegedly be done all on-device, once rooted, with flashfire (thanks, chainfire!), but I haven't bothered with that yet. (And remember, the first rooting requires towelroot which requires old firmware....)
And since that's the method that I learned when a buddy got an S5 last year, which I repeated when I picked up an S5 a bit later, and which I repeated -again- recently when my previous S5 drowned (IP65 my ass), that's the one I write about.
I do not pretend to be an expert on the topic, just someone who has successfully navigated the waters a few times.
Everyone else has already told you what you did wrong 20 years ago. Here's my take: If you were actually rsync'ing all of the user data, then the developer wouldn't have known the difference and would never have had the inkling to turn the old machine back on.
I was speaking more of the head/debris/platter interaction, Bernouli effect, et al: I was raised to understand that a single speck of dust would destroy a hard disk within seconds, that after removing the top cover of a hard drive in other than a clean room environment I might as well toss the entire contraption into the scrap heap because it is surely ruined, forever.
Slashdot Mirror
MS-DOS never ran on an 8080, because MS-DOS didn't exist for the 8080, because the first IBM PC was based on a 4.77MHz 8088 and MS-DOS as we know it was not yet a thing until IBM approached Microsoft about an operating system for said IBM PC.
Meanwhile, an 8086 was a 16-bit CPU with a 16-bit bus, and the (somewhat later) 8088 was a 16-bit CPU with an 8-bit bus. They used the same (16-bit) instruction set.
tl;dr There has never been an 8-bit IBM PC, therefore there is no historical reason for 8-bit MS-DOS.
What Android needs is less-than-terrible audio latency.
Competent UNIX admin? Let me submit that it's just not needed to be competent with UNIX: You just need some basic knowledge of the concept of a subnet, and it might help to know what a broadcast domain is.
Anyone who can configure a venerable WRT54GL with OpenWRT or Tomato or DD-WRT and isn't afraid of a 900MHz ISM-band Ubiquiti (or other) radio can do this.
It's just Ethernet frames that happen to encapsulate IP. No big deal.
I mean, FFS: A couple of years ago I built such a system. A wealthy customer was having a party, and was having circuit issues on the bonded T1s at his house (yep, really) and Really, Really wanted his Sonos system to be reliably online to stream music for his guests.
We sent his wife to the Verizon store, and she came back with an LTE Wifi hotspot. I set up a WRT54GL running Shibby's Tomato-USB as a wireless client put the LTE hotspot in a window where it had reasonable signal. We had another WRT54GL working as a wired client off of this (triple-NAT? so what), which in turn plugged into the Sonos mesh with some Cat5.
DHCP figured out the addressing automagically; all I needed to do was make sure that each WRT54GL was issuing a unique subnet so Linux's routing tables weren't confusing itself.
And....done. It was an ugly hack thrown together late on a Saturday with parts on-hand and it got the party going just fine.
Which is the same as, or perhaps slightly more complicated than, a ProxyHam setup.
Oh, and ProxyHam is easily traceable, too: I haven't actually had my hands on Ubiquiti's 900MHz gear, but their 2.4GHz 802.11N stuff has an excellent and honest spectrum analyzer built-in with the default firmware. I would be shocked and amazed if their 900MHz parts differed in this regard.
A $100 radio, some graph paper, a directional antenna, a working brain and some mobility is all you need to use to triangulate the "isolated" end of a ProxyHam/ProxyGambit connection that is actively being used down to at least the household that the signal emanates from.
Alternatively, any spectrum analyzer that covers whatever band it is that is used to backhaul to the user's location can be used to locate them fairly easily: You can try, but at the end of the day you can never hide while broadcasting with a radio -- especially since we've largely abandoned frequency-hopping spread-spectrum (which was actually rather hard to narrow down using traditional tools).
Rather, you suck at making citations.
The functional difference between a microprocessor-controller washing machine and an electromechanically-controlled washing machine is insufficient to deem one robot, and the other not a robot.
In both cases, the use is the same: Dirty clothes go in. Time passes. Clean, damp clothes come out. Humans do the rest of the work, just as they have now for a very long time.
A modern front-load saves roughly zero human labor over a 60-year-old front-load.
I don't see that number anywhere in the link you provided.
What I do see is that it has a population of 156,462, over 266 square miles. The FD has a budget of $25.6 million. None of that seems unreasonable.
13,000 fire calls, though? Detroit, Michigan is blatantly famous for its ongoing and recurrent structure fires with its population of ~688,000 [citation]. Even Detroit only sees 30,000 fire calls a year, of which 7,000 involve fires that are actually fought.[citation]
Give me a citation that actually supports your claim, or GTFO.
You don't have robots to wash and dry your dishes, or your clothes. Or make ice. Or play videos. Or open or close your garage door.
You have a multitude of relatively dumb machines that do simple things: They spin and/or open and close valves, sometimes with a timer or a small number of sensors (turbidity, etc) to control when the valves open/close and which direction to spin the motor(s).
These dumb machines were doing most of these things way prior to 1943.
A robotic laundry machine will collect the clothes from a pile, sort them as a good housewife would, launder them as appropriate for the material and color, dry them automatically, sort them based on wearer, and stock them as household needs dictate. A good robotic dishwasher will take your stacks of dirty dishes, make them clean, dry them, and install them back in the cabinet where they belong.
These are things that aren't happening and aren't close to happening.
So why wait another decade for robots to catch up? What's special about that 10-year figure other than the fact that you pulled it directly out of your ass?
*shrug*
I've had a few incidental fr0st pists get modded to +5. You've just got to have something to say, and be able to say it quick.
The Chernobyl disaster was in 1986, which was 29 years ago...not 37.
Big words for a guy whose own figures are off by 8 years.
At very busy intersection a block from my house, drivers are presented with a green right-turn arrow at the same time as pedestrians are presented with a walk signal.
(Yes, I've almost been mowed down a few times because of a combination of this and Newtonian physics.)
It is a fact that if the NSA wants to put a magic box in your datacenter, you must accept their magic box into your datacenter and tell noone of its existence, under threat of treason (because terrorism).
Google's good use of HTTPS protects me from the casual middlemen, but it does not protect me from the government in a time of war (we've always been at war with Eastasia).
Me, too. I am consistently amazed at the quality and accuracy of Google Maps' traffic layer, which relies entirely upon location reporting. This data also feeds into both of Google's navigation systems (Waze and Maps).
I also use and appreciate Google's Location History, which I do use to track myself and generate accurate and accountable bills for my clients. This apparently works fine, because nobody has ever questioned any of my bills.
Now, that said: If I were up to no good, I'm also smart enough to leave the cell phone at home.
You agreed to the tracking before your phone even let you use it as a phone. You had the option to disagree. You chose differently than you might have preferred, but you still chose what you chose.
Didn't read the contract you agreed to? Cry me a fucking river. (I see that you've already begun doing that.)
Further, you don't even know what "root" means: It is nothing more than an abstraction of UID 0, and of course there are things running as UID 0. It's fucking Unix. PID 1 (aka init) is executed by the kernel with root (UID 0) privileges, and thereafter can do whatever it is programmed to do.
Get over yourself.
Did you read what you quoted, or were you just feeling disagreeable even though we already agree about that?
Srsly.
If you have an HTPC on your BFT, then why do you care? Just run Kodi or Plex or whatever and be done with it.
Me, I have plenty of old PCs around, but sadly none are up for modern HTPC duty.
I use casting to put my VPN-connected phone (which for all intents and purposes is now in the UK, because again VPN) into a state whereby I can watch the BBC freely. On the BFT. With a $23-$20(rebate-ish) Chromecast.
==win, IMHO. YMMV.
Dear AC,
For all intents and purposes, local Chromecast traffic does not route. It relies on Ethernet broadcast to do its magic (whatever that Ethernet may consist of).
So, the Chromecast must be on the on the same logical LAN as the rest of your network. Can't/won't/don't want to do that? Learn some iptables magic or naff off (good luck!).
Every device in this field is similar in this behavior.
How about: Tab-casting and device-casting (whatever they are called)?
Whatever is on my phone/tablet/whatever, or on a Chrome tab on any manner of modern PC, I can send it to my BFT for the amusement (or profit, in a business setting) of others.
Does the Fire TV do that?
If so, Fire TV is a win because it includes a real UI and a remote. (Unless it is the Fire TV -stick-, and then things get murky before the discussion even starts.)
But if not, then.....sheesh. I expect that my cousins and aunts will be able to link to my Chromecast and show their vacation on the BFT, or that a bunch of drunken friends fighting over Youtube videos in a gathering and a great time will be had by all.
If Fire TV can't do these things, then Chromecast is very social. And Amazon's offerings are de-facto not.
An usb?
An? I recognize that English can be tricky even for folks born in such countries, but sheeshL
Again: "an usb"?
Is there any pronunciation of USB that does elicits an "an"? Or have I been saying U S B wrong all of these years by spelling it out, and should be instead saying "uhsbah"?
Because Webster calls it \ËOEyü-(ËOE)es-ËbÄ"\, and I can't argue with that. (Fucking /. Unicode ruining linguistics yet again, but the link is good.)
Say it out-loud: "A USB," vs. "An USB.": (IE, "A yoo-ess-bee," vs "An yoo-ess-bee")
If the former still sounds more-wrong than the latter, then good luckl with my language!
This is wonderful. The Chromecast's 2.4GHz 802.11n tops out at 72Mbps -- barely better than 802.11g. And while it is begrudgingly slogging in that 72Mbps data, it also is hogging timeslots from devices that could be at ~150 or ~300Mbps if the channel weren't full.
I couldn't reliably stream HD video from the Chromecast app on my Samsung S5 to the Chromecast on 802.11g*. Frames were dropped frequently enough to be a real usability problem, and various disconnects happened enough to make it useless.
I expect that this new adapter will solve the problems with the device that I was experiencing. (Not that it owes me much: I paid $23, shipped, for it on Black Friday, and it came with $20 of Play Store credit that I surely would've used sooner or later anyway.)
*: Incidentally (yes, really incidental) I moved the wireless network that my Chromecast and my phone use from 802.11g to 2.4GHz 802.11n this very afternoon. The streaming of BBC iPlayer via a VPN got a lot better: It didn't freeze or outright stall. It's still a bit rough, though. The phone syncs at 144Mbps, and the Chromecast can't go more than 72. I'd love to say that bandwidth shouldn't be a problem in these modern enlightened times, but apparently it is.
**: As an unreferenced footnote, fixed devices such as Chromecast should always have a hardwired option. Every other*** fixed device on my network is hard-wired; why should the Chromecast not be? I've never carried the Chromecast between TVs, although it's easy enough to do so.
***: Except for the Wii, because that costs extra and its wireless burden is not all that burdensome.
****: The other option I was exploring today was setting up a dedicated access point just for the Chromecast. I've got the hardware, and a bit of room on the outskirts of the ISM band, but fuuuuuu.
*****: TL;DR shut up and take my money
Or, easier: Someone should market some simple extension cables, ala the original Xbox's controller cords.
Trip over the cable? No problem! It orients itself automatically to be easily unplugged mid-span, and neither the laptop nor the person take a spill.
You must have forgotten about Samsung's own 2.5" 9.5mm 2tb HDD, which works in every laptop that I know of.
Which, all told, is still a pain in the ass, I guess:
The OG Droid's rooting process involved using adb to put a special su binary on the device...and, done.
My next two phones (Droid 4, Droid Bionic) both suffered from needing Safestrap and various fuckery to do anything fun.
And now I have an S5, which adds a downgrade to that process. But at least Samsung devices have odin, though, for when everything goes tits-up: Permanently bricking is all but impossible.
There may be a directly-odin flashable way; I don't know. It sure seems like there ought to be; Google it, cunt. ;)
The waters here are murky for me because I'm on Verizon, so I'm blessed with a locked bootloader and therefore none of the cool kids like to play with me. If it were unlocked, I'd probably just install cyanogenmod and call it done.
But the downgrade, as I understand it, is needed because towelroot is needed because, well, it's VZW. And the security exploit that towelroot uses (thanks, geohot!) got fixed a few short months into the S5's life.
The downgrade is also needed because safestrap is awesome (thanks, Hashcode!), but won't run on newer kernels: It still does its thing, with multiple ROM slots and magical flashing of zip files, but its GUI becomes borked.
This can allegedly be done all on-device, once rooted, with flashfire (thanks, chainfire!), but I haven't bothered with that yet. (And remember, the first rooting requires towelroot which requires old firmware....)
And since that's the method that I learned when a buddy got an S5 last year, which I repeated when I picked up an S5 a bit later, and which I repeated -again- recently when my previous S5 drowned (IP65 my ass), that's the one I write about.
I do not pretend to be an expert on the topic, just someone who has successfully navigated the waters a few times.
Everyone else has already told you what you did wrong 20 years ago. Here's my take: If you were actually rsync'ing all of the user data, then the developer wouldn't have known the difference and would never have had the inkling to turn the old machine back on.
I was speaking more of the head/debris/platter interaction, Bernouli effect, et al: I was raised to understand that a single speck of dust would destroy a hard disk within seconds, that after removing the top cover of a hard drive in other than a clean room environment I might as well toss the entire contraption into the scrap heap because it is surely ruined, forever.
Apparently, it doesn't always work that way.