What folks don't realize is that US courts consider "law and equity". That is, the court rules both on the fine legal points established by precedence AND also on what is fair. Most courts would say that the users did NOT consent to giving up their first born because they were not aware the term was there. And you can't consent to what you don't know. This would certainly be the case here because the offending clause was hidden in the fine print. And that is not "fair". So a ruling in equity would be in favor of the users.
That either (a) wouldn't fly, or (b) invalidate nearly all EULAs.
I'd remind him from the real world that he should be glad there are comments at all.
Since for anything to get merged it must pass by Linus, he can insist that you put comments on it or it does not get merged.
The Kernel source actually has quite a few comments, and some very funny jokes running throughout it.
So when dealing with a BDL or core maintainers for a project, you just do what they say as if they were your employer paying you - as any professional would do; or you go do something else.
The whole point is, people should not be subjected to development curves when it is a life and death situation.
If that was the case, you'd never have automobiles to start with, you also wouldn't have airplanes, ships, computers, and more. Much of technology is due to such development curves. The one with Tesla has had far fewer deaths than any prior similar technology.
Doesn't matter. Someone died here. Autopilot needs to drive safely. If it drives as well as a human but no better, why bother paying Tesla for it? Half of all humans are going to be more skilled drivers. Tesla will be causing fatalities for them.
For the majority of people, it would be better - most drivers are not very good - whether due to overconfidence or ineptitude.
Should Tesla aim to make it as safe as possible? Sure, and I'm sure that's their goal. But all technology of this kind goes through a development curve and sometimes the early adopts (as was this case) put too much faith in it and may not pay sufficient attention themselves. They're taking a risk they've been warned against doing.
So yes, the technology will get better and eventually be better than nearly any human driver. Until then, it's an assistant feature that helps but should not be totally relied upon - and that's EXACTLY what Tesla says about it.
"... preliminary data suggests the involvement of the Autopilot feature didn't really make any difference over a human - no better, no worse (e.g the human driver likely would have had the same issue due to the nature of the problem it was faced with)."
Except that this isn't actually the case. The accident happened because the car's radar was unable to detect the truck in front of it because the truck was higher than the radar could detect. Had the human driver been paying attention, he would have seen the truck and stopped.
Oh - and from the preliminary report it could not distinguish the truck from a sun-spot. IOW, it saw the truck but couldn't determine whether it was a truck or sunlight on the sensor. A human would have had similar issues.
"... preliminary data suggests the involvement of the Autopilot feature didn't really make any difference over a human - no better, no worse (e.g the human driver likely would have had the same issue due to the nature of the problem it was faced with)."
Except that this isn't actually the case. The accident happened because the car's radar was unable to detect the truck in front of it because the truck was higher than the radar could detect. Had the human driver been paying attention, he would have seen the truck and stopped.
May be...may be not. I'll wait for the NHTSA report for that kind of determination.
Considering Autopilot only activates on the safest sections of road, three crashes in a month is pretty damn bad.
Considering that last I checked, at least one of those was confirmed that Autopilot was not engaged, and the third is still in question. Now the one where it was engaged was confirmed to have a fatality - it's still under investigation but preliminary data suggests the involvement of the Autopilot feature didn't really make any difference over a human - no better, no worse (e.g the human driver likely would have had the same issue due to the nature of the problem it was faced with).
There has only been 1 crash where Autopilot was confirmed to have been engaged. That could change, but that's been the record thus far, despite what the sensational journalists want you to believe.
...OTOH, KDE had their stuff on Windows since around the release of KDE4 (see windows.kde.org); KDE only lacked Terminal Support (so no Konsole) because Microsoft didn't have a property PTY/console device; and Plasma was capable of replacing the Explorer shell for most of that time though the option was disabled.
However, as you can see it never took off. So don't expect the same for Ubuntu's Unity.
In the US I believe this would be a highly illegal act, does the EU not have similar laws?
Yes, in the US it would be considered collusion and violate both the various Anti-trust Acts (multiple companies banding together and using their combined monopoly power to subvert the market and government) as well as the RICO Act (multiple companies colluding together and racketeering against the public good, extorting the public in the process). This is why you will see AT&T, Verizon, Comcast, TWC/Charter, Cox, etc all file separately (though in agreement with each other) and suggest (but not guarantee) their regulation du jour will impact their business and possibly delay technology, etc - like you all saw with the Net Neutrality and ISP speeds recently - they wouldn't dare sign a single document like that in the US for fear of RICO/etc - their legal counsel would be extremely stupid to allow them to.
The EU regulations AFAIK are a little stronger than those in the US in some ways while in other ways are weaker - mostly from what I've seen regarding EU vs Microsoft; then again these are pretty much all native European companies so they may be able to get away with more than those from across the sea.
While AMD64 does not emulate the i386 as GP so erroneously claimed the problem is that the AMD64 has no i386 mode, it simply supports more registers and op codes so if your i386 build for any reason happen to include any op code from the AMD64 set then it will work on an AMD64 machine but not on a real i386 machine. How VM's do it, i.e if they also support the full AMD64 code set even if you set it to i386 mode, I don't know. If they don't want to keep two code bases they might allow AMD64 codes in i386 mode.
The AMD64 Architecture certainly does support 16/32-bit Real Mode and 16/32-bit Protected Mode with the same meanings and register usages as the IA-32 chipset. The additional registers are not available unless you're in Long Mode (64-bit mode).
Checking AMD x86-64 Architecture Programmer's Manual Vol 1 section 3.1 (my copy is rev 3.07 from 2002) - yes the new 64-bit registers are available in name, but only in so far as they overlap their IA32 named values (e.g rAX -> EAX -> AX -> AL). But that's more a matter of ensuring that your compiler produces the correct values, and is easily enough to have the assembly searched for to validate.
One thing I've always wanted to do was compile up with a really super-duper compiler an emulator for x32 on an IA64 first generation box and compare the performance to the built in emulation which was far from EPIC.
So Bochs Pentium Emulator (bochs.sf.net)? It's performance isn't the best either but it emulates the *entire* computer, but it's decently usable though.
Now, where it may get harder is finding a 32-bit system that is server oriented since most server builders are looking towards packing in the memory beyond the capabilities of a 32-bit system.
The whole argument is nothing more than a straw man. All you have to do is have a multi-boot system where one of the images is 32 bit. Sure, you won't be able to take advantage of all of the RAM, but it will run, just fine. And, you can have one using a PAE kernel so that you can test programs in that environment as well. (Yes, people do use PAE. It's for when you have more than 4 GB RAM but either don't want to nuke, pave and reinstall a 64 bit system or can't because you can't afford the downtime. All you need to do for that is install a PAE kernel and support packages, reboot into it and later, remove the non-PAE packages. And yes, I'm writing from personal experience.)
All true; however, you can't test chip sets that are only available on native 32-bit-only hardware. So there is a limit to what can be tested, which is almost entirely a kernel-land issue not a user-land issue. For user-land, what is not available could have kernel-level emulators used if you really wanted to do so; though timing might change slightly so it's still not the best but it would allow the user-land software to at least function.
My wife likes her iPod and iPad mini; but in both cases we're hitting issues not generally hardware issues but software issues - they can't get upgraded beyond certain versions, and apps, etc are starting to not be available on them so they're coming to be SOL despite being perfectly usable.
Name ANY tech device for which that ISN'T the case. "Support" and "Upgrades" have a lifespan. Apple is almost always near, or at, the top as far as that goes. Time does move on. but it doesn't mean the device, the OS, or the Apps on it magically stop working, does it?, next!
My wife's first (second?) gen iPod Touch. Upgrades only go though I think iOS4. Her iPad Mini I think is only getting upgrades through iOS8.
Of course the key in there is "lifespan" - and the "lifespan" defined by Apple may not be what it is defined by its users. These are still perfectly good devices.
Apple refuses to replace the glass
You mean "under warranty"? Or do you mean "They want to replace the entire Digitizer, when YOU think its just the "glass" that is broken"? Or do you mean "They refuse to even repair it at all at any price"?
Only the glass is broken; and yes we took it to an Apple Store and they said they won't fix it. I doubt warranty had anything to do with it; they would have been happy to give her a discount on a new device if she turned it in, but that was it. So yes, Apple refused to fix it for "any price".
I've advised her of several vendors that claim to do it; but she has yet to take it in. I'm not saying it can't be fixed - it most certainly can. My point was regarding Apple's service, not third party vendor service.
At least for intel Archs, you can install a 32 Bit OS on a computer with a 64 bit capable cpu.
Which doesn't mean squat. We're talking Q.A. here.
The goal is to determine whether the code will work on a real 32-bit architecture, not a 64-bit architecture running in 32-bit emulation mode. The two have differences. If you run the tests on something other than the real target you have no clue whether it will work on the real thing.
IA64/AMD64 do not emulate IA32, they actually support IA32 natively. It's not an Emulation Mode, it's a defined part of the architecture. So yes, you know very well that they run properly. Furthermore, virtual environments for IA32 have been so thoroughly tested that they can be very well relied on for this kind of general testing.
Now, if you want to do some testing of extremely specific hardware devices, that could be a different issue; but the general case of does an image work shouldn't be a problem.
They can still test the software on "better" hardware. They can also run it in a VM. That's what they expect everyone else to do.
It may not be "optimal" but it's certainly possible.
That's not even getting into the fact that they aren't really trying very hard to find 32bit x86 hardware.
I'm having difficulty apprehending what's so difficult to understand about this.
VMs and 64-bit CPUs can use the amd64 image, so there's literally no point in testing the IA-32 image on an amd64 CPU. The point of supporting an IA-32 ISO is so people on i686s and Core Duos can still use them. And you have to *test* to make sure the IA-32 image actually works on those CPUs, else you're at best wasting those peoples' time, at worst wrecking their computers.
You can do those tests on an amd64 system host using a VM just fine. The AMD64 architecture is backwards compatible to x86-32 (IA32). A 32-bit guest is fine for a 64-bit host (not the other way around though).
What's funny is that it's not the Kernel Devs that are complaining. It's Ubuntu which does their own system building (https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0ahUKEwi_r82Hld3NAhUMwYMKHYkGB2AQFggkMAE&url=https%3A%2F%2Finsights.ubuntu.com%2Fwp-content%2Fuploads%2FDS_The_Orange_Box.pdf&usg=AFQjCNGU-_hJXlWHrI2WpOZEOFwz3Er9ag&sig2=hygyf6xsRkCT702uT6ZCNQ). So it's not like Canonical couldn't put together the resources they want to. Even Debian doesn't have an issue, nor does Slackware - both of which have far fewer resources than Canonical does.
"doubles our testing burden (actually, more so, do you know how hard it is to find 32-bit hardware these days?)" I can find 32-bit hardware easily. Obviously, someone who didn't try and claims it not possible.
Agreed. There is a lot of hardware - even new hardware - that is 32-bit; while especially the case in non-x86 systems, there is even x86 systems that are still being shipped in 32-bit mode (e.g 32-bit OS) by default or are 32-bit only, especially in the embedded world - and yes, many of those embedded devices may still operate a GUI interface.
Example: A previous employer was converting from DOS to Linux. We had a GUI interface and the developer just loaded up X-Windows (GNOME I think) and then made a full screen GUI app on top of that. The basic use case was an embedded system (VMIC 7805 Board, Pentium M, - which still sells new) and we were using Ubuntu 8.04 as a base at the time (8.04 was newly released). (FYI VMIC 7805 runs a number of difference OS systems from Windows, Linux, VxWorks, and even DOS.)
So yes, this guy is extremely short sighted - probably looking at MicroCenter or Best Buy and saying "well, no 32-bit systems here, guess we can't buy any". There is plenty of manufacturers you can find to build a 32-bit only system that are desktop oriented.
Now, where it may get harder is finding a 32-bit system that is server oriented since most server builders are looking towards packing in the memory beyond the capabilities of a 32-bit system. Even so, Canonical should have no issue there since they are also doing some system building and could just build their own for their dev farm or just build images in 32-bit only mode to be tested in servers in a datacenter running VMWare, KVM, Xen, etc - a 32-bit guest OS is no issue in a 64-bit host environment.
Kind of...however, there's also been a very big attempt at designing things to fail just outside the warranty period - e.g. make sure it's good enough to get past the warranty then fail so that you have to buy another.
Really? My "computer museum"/Junk Room is the final resting place of nearly a dozen Apple computers from my Apple ][+ on up, and I think only one of them are in a non-working state, despite most of them being over two decades old. I also have a 2005 G5 tower and 2013 MacBook Pro that are in 24/7/365 use. In fact, the 2013 MacBook Pro is my newest Mac. Oh, and my iPad 2 is also well over that year-long warranty, and it gets HEAVILY used every day.
So, speak for your Wintel crap. Apple stuff is made to last...
I typically avoid the expensive Apple stuff, but as others have pointed out Apple has issues too.
My wife likes her iPod and iPad mini; but in both cases we're hitting issues not generally hardware issues but software issues - they can't get upgraded beyond certain versions, and apps, etc are starting to not be available on them so they're coming to be SOL despite being perfectly usable.
Or take her iPad mini, which has been dropped due to the kids and has a shattered screen (not badly but enough to be annoying and create a couple spots where touch doesn't work well). Apple refuses to replace the glass - which is all that is wrong with it (they'll happily sell her a new one and give a discount if she turns it in though), and it's difficult to find a third party vendor to do so either. She still continues to use it.
So yeah, Apple is just as guilty though they do tend to use higher-end components and charge out the wazoo for them to start with so they're not *as* bad as other vendors for Windows and Android products.
Still, my primary point is that the "design to last just beyond warranty" has been something the electronics industry has excelled at for the last 20 years - an Apple ][e is well over that in age. I think a lot of it came in around the dotCom bubble burst in 2000 when they went from trying to compete for the best to trying to build as much recurring revenue as possible and in the process screwing the customer.
You must get bothered easily.
Being that most devices if they are to fail it would be within the first month of operation. That is why it is normal for companies when they get new servers they do a 48 hour burn in session to make sure the server survives the first 48 hours and after that chances are the server will last for the long time.
1 Year or 2 Year isn't really that big of a deal for electronics with little to no moving parts.
The fact that America says one year and the EU says 2, is just legal semantics
Kind of...however, there's also been a very big attempt at designing things to fail just outside the warranty period - e.g. make sure it's good enough to get past the warranty then fail so that you have to buy another.
While I can't say it was purposeful, my Asus Transformer TF700 tablet kind of falls into that category. It worked well for the warranty period, but sometime after became susceptible to what seems heating issue that causes some of the solder to let go and therefore the non-moving components to break down. For a $500 tablet that is simply unacceptable.
Other examples are DVD players that had 90-day warranties, and would generally fail by 120 days - a very common thing 10 years ago and made me reluctant to buy *any* DVD players.
Such is the history of personal electronics in the last 20 years.
Sounds like a great use for Small Claims Court. In the UK it's always at your local court, you don't need a lawyer and it only costs 35 quid (about $3 at today's exchange rate).
In the US one cannot get a lawyer to act on their behalf in small claims court, so unless you yourself are a lawyer you there is no lawyer representation. It's a good way to get a random executive to try to represent the company in court, and often the company just won't show up so you get a default judgement in your favor (at least if you can make a semi-rational argument to the judge with evidence).
You're also limited to total damages of $5,000 USD + court costs.
(I write Windows software, so I need to be up-to-date)
You do? I was writing Windows software but working on Linux. All development, etc was done under Linux. Did a small test on Windows, then pushed it to the customer.
You don't have to stay up-to-date on Windows to do Windows development. Sometimes you actually have to remain behind. For example, if you need to deliver applications to customers using Windows XP or Win2k (because their system can't be upgraded for whatever reason) then you may find yourself hard pressed to use a compiler newer than Visual Studio 2008 or may be 2010. (XP was dropped officially from VS 2012 IIRC), and well, you'll also have trouble running VS2008 on a newer version of Windows too (IIRC, Windows 8/2012 basically had to use VS2010).
C++ is actually used in real programs for a large amount of software you use every day. Go, Swift and Rust aren't even used in the flagship products written by the organizations that created the languages. That should tell you what the difference is.
Go is used by Docker and many tools.
That said, I still find Go to be relatively lacking in many respects (especially around packaging for distribution, which is a major PITA), and the language evolution is still on steroids so things that work today may not in a year due to drastic changes happening. It's better than it use to be but it's still a PITA and requires a significant amount of maintenance as a result.
Slashdot Mirror
What folks don't realize is that US courts consider "law and equity". That is, the court rules both on the fine legal points established by precedence AND also on what is fair. Most courts would say that the users did NOT consent to giving up their first born because they were not aware the term was there. And you can't consent to what you don't know. This would certainly be the case here because the offending clause was hidden in the fine print. And that is not "fair". So a ruling in equity would be in favor of the users.
That either (a) wouldn't fly, or (b) invalidate nearly all EULAs.
... where your password is stored as plaintext in an ACCESS DATABASE!
which really is more secure because, really, who uses Access for anything important?
Far too many. I've seen entire businesses run on Access Databases
I'd remind him from the real world that he should be glad there are comments at all.
Since for anything to get merged it must pass by Linus, he can insist that you put comments on it or it does not get merged.
The Kernel source actually has quite a few comments, and some very funny jokes running throughout it.
So when dealing with a BDL or core maintainers for a project, you just do what they say as if they were your employer paying you - as any professional would do; or you go do something else.
The whole point is, people should not be subjected to development curves when it is a life and death situation.
If that was the case, you'd never have automobiles to start with, you also wouldn't have airplanes, ships, computers, and more. Much of technology is due to such development curves. The one with Tesla has had far fewer deaths than any prior similar technology.
Doesn't matter. Someone died here. Autopilot needs to drive safely. If it drives as well as a human but no better, why bother paying Tesla for it? Half of all humans are going to be more skilled drivers. Tesla will be causing fatalities for them.
For the majority of people, it would be better - most drivers are not very good - whether due to overconfidence or ineptitude.
Should Tesla aim to make it as safe as possible? Sure, and I'm sure that's their goal. But all technology of this kind goes through a development curve and sometimes the early adopts (as was this case) put too much faith in it and may not pay sufficient attention themselves. They're taking a risk they've been warned against doing.
So yes, the technology will get better and eventually be better than nearly any human driver. Until then, it's an assistant feature that helps but should not be totally relied upon - and that's EXACTLY what Tesla says about it.
"... preliminary data suggests the involvement of the Autopilot feature didn't really make any difference over a human - no better, no worse (e.g the human driver likely would have had the same issue due to the nature of the problem it was faced with)."
Except that this isn't actually the case. The accident happened because the car's radar was unable to detect the truck in front of it because the truck was higher than the radar could detect. Had the human driver been paying attention, he would have seen the truck and stopped.
Oh - and from the preliminary report it could not distinguish the truck from a sun-spot. IOW, it saw the truck but couldn't determine whether it was a truck or sunlight on the sensor. A human would have had similar issues.
"... preliminary data suggests the involvement of the Autopilot feature didn't really make any difference over a human - no better, no worse (e.g the human driver likely would have had the same issue due to the nature of the problem it was faced with)."
Except that this isn't actually the case. The accident happened because the car's radar was unable to detect the truck in front of it because the truck was higher than the radar could detect. Had the human driver been paying attention, he would have seen the truck and stopped.
May be...may be not. I'll wait for the NHTSA report for that kind of determination.
experimental? The FAA has a special certification for that. The DMV does not.
Cars are on the ground. They have zero chance of flying over or into buildings unless something has gone _very_ wrong.
But in the event they do, you want to be in a Telsa - see the crash in Germany by the teenage girls.
Considering Autopilot only activates on the safest sections of road, three crashes in a month is pretty damn bad.
Considering that last I checked, at least one of those was confirmed that Autopilot was not engaged, and the third is still in question. Now the one where it was engaged was confirmed to have a fatality - it's still under investigation but preliminary data suggests the involvement of the Autopilot feature didn't really make any difference over a human - no better, no worse (e.g the human driver likely would have had the same issue due to the nature of the problem it was faced with).
There has only been 1 crash where Autopilot was confirmed to have been engaged. That could change, but that's been the record thus far, despite what the sensational journalists want you to believe.
My guess is some people in the media have either bought put-options or want to buy Tesla stock cheap. There is no rationality to their reporting.
Plenty of rationale - it's called sensationalism and sensational journalism - aka anything to get headlines.
...OTOH, KDE had their stuff on Windows since around the release of KDE4 (see windows.kde.org); KDE only lacked Terminal Support (so no Konsole) because Microsoft didn't have a property PTY/console device; and Plasma was capable of replacing the Explorer shell for most of that time though the option was disabled.
However, as you can see it never took off. So don't expect the same for Ubuntu's Unity.
In the US I believe this would be a highly illegal act, does the EU not have similar laws?
Yes, in the US it would be considered collusion and violate both the various Anti-trust Acts (multiple companies banding together and using their combined monopoly power to subvert the market and government) as well as the RICO Act (multiple companies colluding together and racketeering against the public good, extorting the public in the process). This is why you will see AT&T, Verizon, Comcast, TWC/Charter, Cox, etc all file separately (though in agreement with each other) and suggest (but not guarantee) their regulation du jour will impact their business and possibly delay technology, etc - like you all saw with the Net Neutrality and ISP speeds recently - they wouldn't dare sign a single document like that in the US for fear of RICO/etc - their legal counsel would be extremely stupid to allow them to.
The EU regulations AFAIK are a little stronger than those in the US in some ways while in other ways are weaker - mostly from what I've seen regarding EU vs Microsoft; then again these are pretty much all native European companies so they may be able to get away with more than those from across the sea.
While AMD64 does not emulate the i386 as GP so erroneously claimed the problem is that the AMD64 has no i386 mode, it simply supports more registers and op codes so if your i386 build for any reason happen to include any op code from the AMD64 set then it will work on an AMD64 machine but not on a real i386 machine. How VM's do it, i.e if they also support the full AMD64 code set even if you set it to i386 mode, I don't know. If they don't want to keep two code bases they might allow AMD64 codes in i386 mode.
The AMD64 Architecture certainly does support 16/32-bit Real Mode and 16/32-bit Protected Mode with the same meanings and register usages as the IA-32 chipset. The additional registers are not available unless you're in Long Mode (64-bit mode).
Checking AMD x86-64 Architecture Programmer's Manual Vol 1 section 3.1 (my copy is rev 3.07 from 2002) - yes the new 64-bit registers are available in name, but only in so far as they overlap their IA32 named values (e.g rAX -> EAX -> AX -> AL). But that's more a matter of ensuring that your compiler produces the correct values, and is easily enough to have the assembly searched for to validate.
One thing I've always wanted to do was compile up with a really super-duper compiler an emulator for x32 on an IA64 first generation box and compare the performance to the built in emulation which was far from EPIC.
So Bochs Pentium Emulator (bochs.sf.net)? It's performance isn't the best either but it emulates the *entire* computer, but it's decently usable though.
Now, where it may get harder is finding a 32-bit system that is server oriented since most server builders are looking towards packing in the memory beyond the capabilities of a 32-bit system. The whole argument is nothing more than a straw man. All you have to do is have a multi-boot system where one of the images is 32 bit. Sure, you won't be able to take advantage of all of the RAM, but it will run, just fine. And, you can have one using a PAE kernel so that you can test programs in that environment as well. (Yes, people do use PAE. It's for when you have more than 4 GB RAM but either don't want to nuke, pave and reinstall a 64 bit system or can't because you can't afford the downtime. All you need to do for that is install a PAE kernel and support packages, reboot into it and later, remove the non-PAE packages. And yes, I'm writing from personal experience.)
All true; however, you can't test chip sets that are only available on native 32-bit-only hardware. So there is a limit to what can be tested, which is almost entirely a kernel-land issue not a user-land issue. For user-land, what is not available could have kernel-level emulators used if you really wanted to do so; though timing might change slightly so it's still not the best but it would allow the user-land software to at least function.
My wife likes her iPod and iPad mini; but in both cases we're hitting issues not generally hardware issues but software issues - they can't get upgraded beyond certain versions, and apps, etc are starting to not be available on them so they're coming to be SOL despite being perfectly usable.
Name ANY tech device for which that ISN'T the case. "Support" and "Upgrades" have a lifespan. Apple is almost always near, or at, the top as far as that goes. Time does move on. but it doesn't mean the device, the OS, or the Apps on it magically stop working, does it?, next!
My wife's first (second?) gen iPod Touch. Upgrades only go though I think iOS4. Her iPad Mini I think is only getting upgrades through iOS8.
Of course the key in there is "lifespan" - and the "lifespan" defined by Apple may not be what it is defined by its users. These are still perfectly good devices.
Apple refuses to replace the glass
You mean "under warranty"? Or do you mean "They want to replace the entire Digitizer, when YOU think its just the "glass" that is broken"? Or do you mean "They refuse to even repair it at all at any price"?
Only the glass is broken; and yes we took it to an Apple Store and they said they won't fix it. I doubt warranty had anything to do with it; they would have been happy to give her a discount on a new device if she turned it in, but that was it. So yes, Apple refused to fix it for "any price".
And of course, your statement "it's difficult to find a third-party vendor to do it" exposes you for being either a bald-faced liar (more likely) or a complete idiot. Heck, if you're not a complete klutz, you can even do it yourself (which I think was the whole point of TFA) iFixit even has some nice step-by-step guides, what more could you want?
I've advised her of several vendors that claim to do it; but she has yet to take it in. I'm not saying it can't be fixed - it most certainly can. My point was regarding Apple's service, not third party vendor service.
At least for intel Archs, you can install a 32 Bit OS on a computer with a 64 bit capable cpu.
Which doesn't mean squat. We're talking Q.A. here.
The goal is to determine whether the code will work on a real 32-bit architecture, not a 64-bit architecture running in 32-bit emulation mode. The two have differences. If you run the tests on something other than the real target you have no clue whether it will work on the real thing.
IA64/AMD64 do not emulate IA32, they actually support IA32 natively. It's not an Emulation Mode, it's a defined part of the architecture. So yes, you know very well that they run properly. Furthermore, virtual environments for IA32 have been so thoroughly tested that they can be very well relied on for this kind of general testing.
Now, if you want to do some testing of extremely specific hardware devices, that could be a different issue; but the general case of does an image work shouldn't be a problem.
They can still test the software on "better" hardware. They can also run it in a VM. That's what they expect everyone else to do.
It may not be "optimal" but it's certainly possible.
That's not even getting into the fact that they aren't really trying very hard to find 32bit x86 hardware.
I'm having difficulty apprehending what's so difficult to understand about this. VMs and 64-bit CPUs can use the amd64 image, so there's literally no point in testing the IA-32 image on an amd64 CPU. The point of supporting an IA-32 ISO is so people on i686s and Core Duos can still use them. And you have to *test* to make sure the IA-32 image actually works on those CPUs, else you're at best wasting those peoples' time, at worst wrecking their computers.
You can do those tests on an amd64 system host using a VM just fine. The AMD64 architecture is backwards compatible to x86-32 (IA32). A 32-bit guest is fine for a 64-bit host (not the other way around though).
What's funny is that it's not the Kernel Devs that are complaining. It's Ubuntu which does their own system building (https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0ahUKEwi_r82Hld3NAhUMwYMKHYkGB2AQFggkMAE&url=https%3A%2F%2Finsights.ubuntu.com%2Fwp-content%2Fuploads%2FDS_The_Orange_Box.pdf&usg=AFQjCNGU-_hJXlWHrI2WpOZEOFwz3Er9ag&sig2=hygyf6xsRkCT702uT6ZCNQ). So it's not like Canonical couldn't put together the resources they want to. Even Debian doesn't have an issue, nor does Slackware - both of which have far fewer resources than Canonical does.
"doubles our testing burden (actually, more so, do you know how hard it is to find 32-bit hardware these days?)" I can find 32-bit hardware easily. Obviously, someone who didn't try and claims it not possible.
Agreed. There is a lot of hardware - even new hardware - that is 32-bit; while especially the case in non-x86 systems, there is even x86 systems that are still being shipped in 32-bit mode (e.g 32-bit OS) by default or are 32-bit only, especially in the embedded world - and yes, many of those embedded devices may still operate a GUI interface.
Example: A previous employer was converting from DOS to Linux. We had a GUI interface and the developer just loaded up X-Windows (GNOME I think) and then made a full screen GUI app on top of that. The basic use case was an embedded system (VMIC 7805 Board, Pentium M, - which still sells new) and we were using Ubuntu 8.04 as a base at the time (8.04 was newly released). (FYI VMIC 7805 runs a number of difference OS systems from Windows, Linux, VxWorks, and even DOS.)
So yes, this guy is extremely short sighted - probably looking at MicroCenter or Best Buy and saying "well, no 32-bit systems here, guess we can't buy any". There is plenty of manufacturers you can find to build a 32-bit only system that are desktop oriented.
Now, where it may get harder is finding a 32-bit system that is server oriented since most server builders are looking towards packing in the memory beyond the capabilities of a 32-bit system. Even so, Canonical should have no issue there since they are also doing some system building and could just build their own for their dev farm or just build images in 32-bit only mode to be tested in servers in a datacenter running VMWare, KVM, Xen, etc - a 32-bit guest OS is no issue in a 64-bit host environment.
Kind of...however, there's also been a very big attempt at designing things to fail just outside the warranty period - e.g. make sure it's good enough to get past the warranty then fail so that you have to buy another.
Really? My "computer museum"/Junk Room is the final resting place of nearly a dozen Apple computers from my Apple ][+ on up, and I think only one of them are in a non-working state, despite most of them being over two decades old. I also have a 2005 G5 tower and 2013 MacBook Pro that are in 24/7/365 use. In fact, the 2013 MacBook Pro is my newest Mac. Oh, and my iPad 2 is also well over that year-long warranty, and it gets HEAVILY used every day. So, speak for your Wintel crap. Apple stuff is made to last...
I typically avoid the expensive Apple stuff, but as others have pointed out Apple has issues too.
My wife likes her iPod and iPad mini; but in both cases we're hitting issues not generally hardware issues but software issues - they can't get upgraded beyond certain versions, and apps, etc are starting to not be available on them so they're coming to be SOL despite being perfectly usable.
Or take her iPad mini, which has been dropped due to the kids and has a shattered screen (not badly but enough to be annoying and create a couple spots where touch doesn't work well). Apple refuses to replace the glass - which is all that is wrong with it (they'll happily sell her a new one and give a discount if she turns it in though), and it's difficult to find a third party vendor to do so either. She still continues to use it.
So yeah, Apple is just as guilty though they do tend to use higher-end components and charge out the wazoo for them to start with so they're not *as* bad as other vendors for Windows and Android products.
Still, my primary point is that the "design to last just beyond warranty" has been something the electronics industry has excelled at for the last 20 years - an Apple ][e is well over that in age. I think a lot of it came in around the dotCom bubble burst in 2000 when they went from trying to compete for the best to trying to build as much recurring revenue as possible and in the process screwing the customer.
You must get bothered easily. Being that most devices if they are to fail it would be within the first month of operation. That is why it is normal for companies when they get new servers they do a 48 hour burn in session to make sure the server survives the first 48 hours and after that chances are the server will last for the long time.
1 Year or 2 Year isn't really that big of a deal for electronics with little to no moving parts.
The fact that America says one year and the EU says 2, is just legal semantics
Kind of...however, there's also been a very big attempt at designing things to fail just outside the warranty period - e.g. make sure it's good enough to get past the warranty then fail so that you have to buy another.
While I can't say it was purposeful, my Asus Transformer TF700 tablet kind of falls into that category. It worked well for the warranty period, but sometime after became susceptible to what seems heating issue that causes some of the solder to let go and therefore the non-moving components to break down. For a $500 tablet that is simply unacceptable.
Other examples are DVD players that had 90-day warranties, and would generally fail by 120 days - a very common thing 10 years ago and made me reluctant to buy *any* DVD players.
Such is the history of personal electronics in the last 20 years.
Sounds like a great use for Small Claims Court. In the UK it's always at your local court, you don't need a lawyer and it only costs 35 quid (about $3 at today's exchange rate).
In the US one cannot get a lawyer to act on their behalf in small claims court, so unless you yourself are a lawyer you there is no lawyer representation. It's a good way to get a random executive to try to represent the company in court, and often the company just won't show up so you get a default judgement in your favor (at least if you can make a semi-rational argument to the judge with evidence).
You're also limited to total damages of $5,000 USD + court costs.
(I write Windows software, so I need to be up-to-date)
You do? I was writing Windows software but working on Linux. All development, etc was done under Linux. Did a small test on Windows, then pushed it to the customer.
You don't have to stay up-to-date on Windows to do Windows development. Sometimes you actually have to remain behind. For example, if you need to deliver applications to customers using Windows XP or Win2k (because their system can't be upgraded for whatever reason) then you may find yourself hard pressed to use a compiler newer than Visual Studio 2008 or may be 2010. (XP was dropped officially from VS 2012 IIRC), and well, you'll also have trouble running VS2008 on a newer version of Windows too (IIRC, Windows 8/2012 basically had to use VS2010).
I dunno. I googled NC++17. I got pretty much the results I expected/hoped for.
Googling "C++17" is a tons more fun.
C++ is actually used in real programs for a large amount of software you use every day. Go, Swift and Rust aren't even used in the flagship products written by the organizations that created the languages. That should tell you what the difference is.
Go is used by Docker and many tools.
That said, I still find Go to be relatively lacking in many respects (especially around packaging for distribution, which is a major PITA), and the language evolution is still on steroids so things that work today may not in a year due to drastic changes happening. It's better than it use to be but it's still a PITA and requires a significant amount of maintenance as a result.