Not many people could afford it but with so many things signed by Woz and being PCB 64 on top of that, it could be worth a small fortune.
If I can work out the logistics, I'm going to get Woz to sign mine. But if I can't work that out, Woz has already told me he would sign an affidavit attesting to the fact that he has known me since 1978, and knows that I have owned that since we first talked, etc...
Yeah, the SN is written on the back of the PCB with black Sharpie, which is the way some of the first ones were.
"They had an intricate wood-cut logo, not much money or manpower, and their first computer only sold about 175 units"
And if you can find one of these units, they are still the most expensive product that Apple has ever sold
I have one (No fooling). "Serial No." written on the back of the PCB reads "0064". Fully decked-out with 8 kB RAM and that wonderful cassette interface board. Also has a case, Datatronics (IIRC) keyboard, and video RF modulator. With manuals, Woz's Integer BASIC on cassette (unfortunately a "dub" on a "Poly88"-labeled tape!), and a bunch of other Apple 1 software that I've scraped-up on a CD.
Traded some computer work for it in 1977.
Had it, one-owner, since then.
I also have an original "Woz Pak", sent to me by Woz himself in 1978 (IIRC). And a couple of vintage Kilobaud and Byte magazines with articles like "Sweet 16: The 6502 Dream Machine", authored by Woz.
What about server whose job it is to sit and wait for clients to connect? Does that need a timeout?
You don't read so well, do you?
I specifically limited that hypothetical "special place in Hell" to those Devs. who were writing code that waited for a HANDSHAKE.
If you don't know the difference between that scenario and "waiting for a login", (which, BTW, is NOT what a "Server" "sits and waits for"), then you obviously shouldn't be commenting on my Post in the first place.
If it was just one app that broke it, one not just remove the app? Why does iOS need to be updated to fix the behavior of a buggy app? Isn't the App Store supposed to be curated, blocking misbehaving apps from ever making it to a user's phone?
Your answer still means Apple is incredibly bad at software QA.
Because, you frickin' nitwit, it wasn't an issue until Apple added the "Universal Links" feature to iOS.
So, do you want Apple to now do a code-review of every possible App ALREADY IN THE STORE to see if it is abusive in this manner?
And besides, I don't think it was the APP's fault anyway; it is the (e.g.booking.com) WEBSITE's behavior that who's behavior is outside all reason. And Apple has no control over that. So they had no choice but to patch the OS to handle the ridiculous data-flooding.
Their QA department somehow missed that iOS 9.3 made it so that links broke in the mobile browser.
The reason it didn't get caught was that only a very few websites try to cram multi-MEGABYTES of "related-links" data down a browser's throat when the user simply clicked on a single link.
So, howabout you share some of that copious hatred for the stupid-ass web developer that thought it was ok to send every URL on the interwebs (yes, I know that's much more than a few MB) to your browser just because the user clicked on a single link.
I've seen it happen a lot on servers. It usually happens because the process is already suspended while waiting for a resource to be freed. Like trying to get an exclusive lock on a network shared file after the connection is lost. As it is waiting for a response from the network, it's put in a suspended state. But since there is no connection, there's never going to be a reply. So it just waits and waits.
Sending a kill signal might nudge it closer to the afterlife and get local resource freed, but when remote resources on network servers are tried to be released, it locks up.
IMHO, there's a special place in Hell for Developers that write code that waits for a handshake, but then don't put some sort of a reasonable timeout in the code. Really, even if we're talking about waiting for something to respond through a Dialup connection, if that resource isn't available in a couple of hours, it probably is safe to assume it ain't comin' back.
So, unless you're writing code to collect data from outer space, there's absolutely no reason to "wait forever" (and even then, "forever" is too frickin' long)...
Android is Open Source. Or at least historically has been. Giving the source to the carriers isn't a bad thing. It's the behavior of the carriers that's the problem. Even if the OS were closed source, some vendors would choose to implement these 'features' on behalf of the carrier. I don't think we should portray the distribution of source code as something negative that enables bad behavior.
And perhaps that also illustrates why being slavish to F/OSS in ALL situations (ala RMS) is not always the best approach.
iOS stays blissfully Bloatware-Free in large part because it is Closed-Source. Plus, it makes it all the harder for malware-writers (and Nation-States) to discover and exploit vulnerabilities.
Sometimes, "Many Eyes" aren't really what you want. And considering how many F/OSS projects have support issue after support issue that languish for long periods of time (not to say that some Closed Source doesn't), perhaps "Many Eyes" isn't really the panacea that F/OSSbois hold it out to be.
As an AT&T customer let me say this, I totally and completely hate the utter garbage that is AT&T bloatware and that they shove down their customers' throats. And to make the offense even more egregious, they make it very difficult to remove the said junk.
I buy Nexus devices now so that I do have to deal with this shit. What a clueless company.
Please don't tell me to go to Verizon, they do the same thing. And so does Sprint. T-mobile might not, but they don't have the coverage I need.
Funny, I have an AT&T "sponsored" iPhone, and I don't think it has a single byte of AT&T bloatware on it.
Perhaps LG, Samsung, HTC need to man-up the next time if is time to renew contracts, instead of just seeing how many units they can dump on the Carrier, then giving them the Source to their OS, so that said Carrier can fuck over its customers with Bloatware.
Between Apple's ridiculously overpriced hardware and overblown software restrictions,
Apple's phones aren't overpriced: they just don't make the low-end crap that you will try and use as "proof" that Apple is overpriced. And if you compare the malware history of Android vs. IOS, perhaps a reasonable person (but I'm sure that's not you) would conclude that those software restrictions aren't so "overblown" after all.
I doubt they could succeed in this manner. Regardless of what the DMCA says, there's the principle of rex non potest paccare, translated roughly to the King can do no wrong. It's not codified in US law anywhere, but this is the legal doctrine of sovereign immunity. I don't see any exception to sovereign immunity that would allow Apple to succeed in bringing such a suit against the US government. The only way this would work is for Congress to specifically allow such a lawsuit, which seems highly unlikely.
Fine. But what about the NON governmental agency that allegedly did the hacking? I'm not at all sure they inherit that bogus Sovereign Immunity, especially since there was never actually a Court Order, only a Proposed Order.
Shouldn't Apple be chasing after them for circumventing the encryption and digital rights management system on the phone? Its what they do to people coming up with jailbreaks... why would this be diffrent?
I was thinking about that federal law about "Unauthorized Access to a computer" and/or the "circumventing security measures" law. Both the FBI and/or the supposed "hackers" are guilty of these felonies, period.
And before you say "Court Order", I believe it was just a PROPOSED Order; I don't think it ever became a real Order. And besides, even a Court can't enter an Order to Break the Law...
It's a very well known corner case and one of the first things you're supposed to check for. When receiving any type of input, you write checks for missing input, massive input, and malformed input. If you're not always doing those things, you shouldn't call yourself a tester (really the developer should have handled all these first anyway). This is one of the most basic QA things you're taught in any decent software engineering degree. Never trust input!
I seem to recall browsers having issues with long URLs in the news a few years ago.
If you read my post again, you will notice that I never said that Apple was blameless in this. I know that you should never trust input data. And I assure you that the iOS OS Dev. That wrote the code for that feature knows that, too. To assume otherwise is patently ridiculous, and you know it, or should...
But what I pointed out was that I know from experience that it is an "understandable" error. You can get up on your high-horse all you want; but if you have been coding (or testing) for more than a year, you have probably had errors crop up in code "in the field" that you just didn't anticipate. And, I'll bet that you sometimes went "Yeah, I probably shoulda checked for that."
There's an old Engineering adage: "You can't make things foolproof; because fools are too clever."
a) databases by nature are suppose to handle 1000s of entires no problem. a 2.8MB database should be cake to search through; the code behind it shouldn't care how many entries are in the database or that it would take a bit longer than normal to find what it's looking for.
The ONLY thing I will "fault" Apple on in this case is not limits-checking. It should reject new entries or throw an error when the table-size is exceeeded. But the rest of it is simply the fault of a web-developer that didn't know how to code THEIR side. Clearly, shoving 2.8 MB of "link data" to a mobile device is OBSCENELY bad-practice.
Apple have lately had a pretty big string of shoddy QA/QC on their products. Remember when a software update disabled all those brand new iPhone 6/6+s? They're supporting a very small number of platforms and struggling to test them all. How many iPhone alarm clock bugs were there? It was year after year. Time changes, new years, leap years, all the boundary conditions any developer with half a brain would test.
Easy for you to say. All software has bugs. Sometimes those bugs seem to go on forever. Happens on Every. Single. Platform.
Also known as the Apple model of hardware development. Ship it now, offer a fix in 4 months for the shoddy work, then discontinue support for your 7 month old phone and release a new one.
Since they still support the iPad 2 and the iPhone 4s, you are clearly talking out your ass, hater.
It's interesting to see such a large company letting a bug like this slip by, especially in an operating system. You would think even with an Agile "ship it broken, we'll patch later" mentality, they would have armies of QA people and automated scripts banging away at every corner of the OS. Something like "clicking on any link in our bundled browser with JavaScript turned on crashes the application" seems to me like a showstopper bug.
I'm all for getting stuff rolled out in a reasonable time frame, but core stuff like an operating system needs to be tested a lot more intensely than some social media/dating app. Not everyone is connected 24/7 with easy access to patches...the product I currently do systems engineering work for is used almost exclusively in offline environments.
If you develop software, then you know how easy it is to fall into a "testing rut". You put together test data/round-up the URLs of some sites, and use those during your Development.
Who would suspect that some stupid web-developer at the other end would try and shove megabytes worth of "link" data down your throat when you so much as clicked on a SINGLE LINK?
Customers like paying 30% of their payment to a company that's already making billions, what can you say?
Human nature at it's finest.
So how much, pray tell, would be an acceptable amount for Apple to charge Developers for hosting, payment acceptance, cataloging, and providing a storefront where ALL users of your target platform WILL (have) to come to for your Appy-App-Appness?
Because AFAICT, pretty much ALL of the "App/Play Store" models take the same "cut". I think that MS was only charging 20%; but they were desperate for content.
Oh, and there's a way around that "usurious" 30%. Just list your App for FREE. Apple will STILL do all those things above, and NOT charge you ANYTHING (30% of zero is...).
Slashdot Mirror
Not many people could afford it but with so many things signed by Woz and being PCB 64 on top of that, it could be worth a small fortune.
If I can work out the logistics, I'm going to get Woz to sign mine. But if I can't work that out, Woz has already told me he would sign an affidavit attesting to the fact that he has known me since 1978, and knows that I have owned that since we first talked, etc...
Yeah, the SN is written on the back of the PCB with black Sharpie, which is the way some of the first ones were.
A fully functional Apple I can go for... half a million dollars. No joke.
The Henry Ford museum in the USA paid $950K for one about a year ago.
Why do you think I am being so careful to bring it back up again? So far, so good, BTW...
at their peak
Unfortunately, Microsoft's peak was sometime in the mid 1990s.
"They had an intricate wood-cut logo, not much money or manpower, and their first computer only sold about 175 units"
And if you can find one of these units, they are still the most expensive product that Apple has ever sold
I have one (No fooling). "Serial No." written on the back of the PCB reads "0064". Fully decked-out with 8 kB RAM and that wonderful cassette interface board. Also has a case, Datatronics (IIRC) keyboard, and video RF modulator. With manuals, Woz's Integer BASIC on cassette (unfortunately a "dub" on a "Poly88"-labeled tape!), and a bunch of other Apple 1 software that I've scraped-up on a CD.
Traded some computer work for it in 1977.
Had it, one-owner, since then.
I also have an original "Woz Pak", sent to me by Woz himself in 1978 (IIRC). And a couple of vintage Kilobaud and Byte magazines with articles like "Sweet 16: The 6502 Dream Machine", authored by Woz.
Anyone interested?
What about server whose job it is to sit and wait for clients to connect? Does that need a timeout?
You don't read so well, do you?
I specifically limited that hypothetical "special place in Hell" to those Devs. who were writing code that waited for a HANDSHAKE.
If you don't know the difference between that scenario and "waiting for a login", (which, BTW, is NOT what a "Server" "sits and waits for"), then you obviously shouldn't be commenting on my Post in the first place.
The solution to that is obvious. Apple should create a HTML extension tag and coerce everyone into using it.
Ah, the Microsoft way of "following" standards.
If it was just one app that broke it, one not just remove the app? Why does iOS need to be updated to fix the behavior of a buggy app? Isn't the App Store supposed to be curated, blocking misbehaving apps from ever making it to a user's phone?
Your answer still means Apple is incredibly bad at software QA.
Because, you frickin' nitwit, it wasn't an issue until Apple added the "Universal Links" feature to iOS.
.booking.com) WEBSITE's behavior that who's behavior is outside all reason. And Apple has no control over that. So they had no choice but to patch the OS to handle the ridiculous data-flooding.
So, do you want Apple to now do a code-review of every possible App ALREADY IN THE STORE to see if it is abusive in this manner?
And besides, I don't think it was the APP's fault anyway; it is the (e.g
Their QA department somehow missed that iOS 9.3 made it so that links broke in the mobile browser.
The reason it didn't get caught was that only a very few websites try to cram multi-MEGABYTES of "related-links" data down a browser's throat when the user simply clicked on a single link.
So, howabout you share some of that copious hatred for the stupid-ass web developer that thought it was ok to send every URL on the interwebs (yes, I know that's much more than a few MB) to your browser just because the user clicked on a single link.
I've seen it happen a lot on servers. It usually happens because the process is already suspended while waiting for a resource to be freed. Like trying to get an exclusive lock on a network shared file after the connection is lost. As it is waiting for a response from the network, it's put in a suspended state. But since there is no connection, there's never going to be a reply. So it just waits and waits.
Sending a kill signal might nudge it closer to the afterlife and get local resource freed, but when remote resources on network servers are tried to be released, it locks up.
IMHO, there's a special place in Hell for Developers that write code that waits for a handshake, but then don't put some sort of a reasonable timeout in the code. Really, even if we're talking about waiting for something to respond through a Dialup connection, if that resource isn't available in a couple of hours, it probably is safe to assume it ain't comin' back.
So, unless you're writing code to collect data from outer space, there's absolutely no reason to "wait forever" (and even then, "forever" is too frickin' long)...
Android is Open Source. Or at least historically has been. Giving the source to the carriers isn't a bad thing. It's the behavior of the carriers that's the problem. Even if the OS were closed source, some vendors would choose to implement these 'features' on behalf of the carrier. I don't think we should portray the distribution of source code as something negative that enables bad behavior.
And perhaps that also illustrates why being slavish to F/OSS in ALL situations (ala RMS) is not always the best approach.
iOS stays blissfully Bloatware-Free in large part because it is Closed-Source. Plus, it makes it all the harder for malware-writers (and Nation-States) to discover and exploit vulnerabilities.
Sometimes, "Many Eyes" aren't really what you want. And considering how many F/OSS projects have support issue after support issue that languish for long periods of time (not to say that some Closed Source doesn't), perhaps "Many Eyes" isn't really the panacea that F/OSSbois hold it out to be.
years old tech at premium prices is overpriced.
and selling old models they stop updating sw for a few months later. apple does that.
Citation, please?
Holy fuck macfag, slow your shilling, you still get paid the same flat rate per post.
Can't stand the truth, can you?
"period" belongs to spoken language. In written language there is a symbol for it.
You have a weak grasp on the English language, period.
As an AT&T customer let me say this, I totally and completely hate the utter garbage that is AT&T bloatware and that they shove down their customers' throats. And to make the offense even more egregious, they make it very difficult to remove the said junk. I buy Nexus devices now so that I do have to deal with this shit. What a clueless company. Please don't tell me to go to Verizon, they do the same thing. And so does Sprint. T-mobile might not, but they don't have the coverage I need.
Funny, I have an AT&T "sponsored" iPhone, and I don't think it has a single byte of AT&T bloatware on it.
Perhaps LG, Samsung, HTC need to man-up the next time if is time to renew contracts, instead of just seeing how many units they can dump on the Carrier, then giving them the Source to their OS, so that said Carrier can fuck over its customers with Bloatware.
Between Apple's ridiculously overpriced hardware and overblown software restrictions,
Apple's phones aren't overpriced: they just don't make the low-end crap that you will try and use as "proof" that Apple is overpriced. And if you compare the malware history of Android vs. IOS, perhaps a reasonable person (but I'm sure that's not you) would conclude that those software restrictions aren't so "overblown" after all.
I doubt they could succeed in this manner. Regardless of what the DMCA says, there's the principle of rex non potest paccare, translated roughly to the King can do no wrong. It's not codified in US law anywhere, but this is the legal doctrine of sovereign immunity. I don't see any exception to sovereign immunity that would allow Apple to succeed in bringing such a suit against the US government. The only way this would work is for Congress to specifically allow such a lawsuit, which seems highly unlikely.
Fine. But what about the NON governmental agency that allegedly did the hacking? I'm not at all sure they inherit that bogus Sovereign Immunity, especially since there was never actually a Court Order, only a Proposed Order.
Shouldn't Apple be chasing after them for circumventing the encryption and digital rights management system on the phone? Its what they do to people coming up with jailbreaks... why would this be diffrent?
I was thinking about that federal law about "Unauthorized Access to a computer" and/or the "circumventing security measures" law. Both the FBI and/or the supposed "hackers" are guilty of these felonies, period.
And before you say "Court Order", I believe it was just a PROPOSED Order; I don't think it ever became a real Order. And besides, even a Court can't enter an Order to Break the Law...
It's a very well known corner case and one of the first things you're supposed to check for. When receiving any type of input, you write checks for missing input, massive input, and malformed input. If you're not always doing those things, you shouldn't call yourself a tester (really the developer should have handled all these first anyway). This is one of the most basic QA things you're taught in any decent software engineering degree. Never trust input!
I seem to recall browsers having issues with long URLs in the news a few years ago.
If you read my post again, you will notice that I never said that Apple was blameless in this. I know that you should never trust input data. And I assure you that the iOS OS Dev. That wrote the code for that feature knows that, too. To assume otherwise is patently ridiculous, and you know it, or should...
But what I pointed out was that I know from experience that it is an "understandable" error. You can get up on your high-horse all you want; but if you have been coding (or testing) for more than a year, you have probably had errors crop up in code "in the field" that you just didn't anticipate. And, I'll bet that you sometimes went "Yeah, I probably shoulda checked for that."
There's an old Engineering adage: "You can't make things foolproof; because fools are too clever."
a) databases by nature are suppose to handle 1000s of entires no problem. a 2.8MB database should be cake to search through; the code behind it shouldn't care how many entries are in the database or that it would take a bit longer than normal to find what it's looking for.
The ONLY thing I will "fault" Apple on in this case is not limits-checking. It should reject new entries or throw an error when the table-size is exceeeded. But the rest of it is simply the fault of a web-developer that didn't know how to code THEIR side. Clearly, shoving 2.8 MB of "link data" to a mobile device is OBSCENELY bad-practice.
Apple have lately had a pretty big string of shoddy QA/QC on their products. Remember when a software update disabled all those brand new iPhone 6/6+s? They're supporting a very small number of platforms and struggling to test them all. How many iPhone alarm clock bugs were there? It was year after year. Time changes, new years, leap years, all the boundary conditions any developer with half a brain would test.
Easy for you to say. All software has bugs. Sometimes those bugs seem to go on forever. Happens on Every. Single. Platform.
Stop simply hating and start thinking.
Also known as the Apple model of hardware development. Ship it now, offer a fix in 4 months for the shoddy work, then discontinue support for your 7 month old phone and release a new one.
Since they still support the iPad 2 and the iPhone 4s, you are clearly talking out your ass, hater.
It's interesting to see such a large company letting a bug like this slip by, especially in an operating system. You would think even with an Agile "ship it broken, we'll patch later" mentality, they would have armies of QA people and automated scripts banging away at every corner of the OS. Something like "clicking on any link in our bundled browser with JavaScript turned on crashes the application" seems to me like a showstopper bug.
I'm all for getting stuff rolled out in a reasonable time frame, but core stuff like an operating system needs to be tested a lot more intensely than some social media/dating app. Not everyone is connected 24/7 with easy access to patches...the product I currently do systems engineering work for is used almost exclusively in offline environments.
If you develop software, then you know how easy it is to fall into a "testing rut". You put together test data/round-up the URLs of some sites, and use those during your Development.
Who would suspect that some stupid web-developer at the other end would try and shove megabytes worth of "link" data down your throat when you so much as clicked on a SINGLE LINK?
This was an corner-case, clearly.
Customers like paying 30% of their payment to a company that's already making billions, what can you say?
Human nature at it's finest.
So how much, pray tell, would be an acceptable amount for Apple to charge Developers for hosting, payment acceptance, cataloging, and providing a storefront where ALL users of your target platform WILL (have) to come to for your Appy-App-Appness?
Because AFAICT, pretty much ALL of the "App/Play Store" models take the same "cut". I think that MS was only charging 20%; but they were desperate for content.
Oh, and there's a way around that "usurious" 30%. Just list your App for FREE. Apple will STILL do all those things above, and NOT charge you ANYTHING (30% of zero is...).
So, why don't you just STFU and DIE, hater?
f.lux does support Philips Hue lighting and will adjust the room color in conjunction with your display. Except if you're running the OSX version.
Why not in OS X?
Because OS X sucks and doesn't have necessary api's/services to do that?
To do what, exactly?
Oh, that's right: You have absolutely no idea! Because if you did, you would have simply told me that it's coming in the next f.lux update.
f.lux does support Philips Hue lighting and will adjust the room color in conjunction with your display. Except if you're running the OSX version.
Why not in OS X?