Do you remember why AWS exists? Amazon had to have enough servers to handle peak buying times, but most of the time a load of them were sitting idle. They realised that they could make money by selling the idle cycles. The cost of this spare time to Amazon is a lot less than the cost of buying, powering, cooling, and connecting a machine would be to you. Google works the same way: their attitude to power management is that the machines should be running at 100% load all of the time, and if they aren't then you bought too many of them.
It wasn't always. The founders cared a lot about privacy and had a reasonable business model (free for the first year, $1 for each year after that. The servers were FreeBSD boxes running an Erlang stack and so the server cost per user was well under $1/year). Then Facebook bought them and it all went downhill.
The post said that it was a problem with DOSBox interacting with the hardware. DOSBox emulates some hardware, but doesn't allow direct access to the underlying hardware for anything running in the emulator. Access to serial and parallel ports more or less works for common uses, but for anything else it doesn't work (see the DOSBox documentation section about why you probably won't be able to get printing working). In contrast, FreeDOS provides the same abstractions as MS-DOS (i.e. very few) and permits direct access to the hardware. Stuff that needs to poke the serial UART directly with realtime timing constraints will work fine with FreeDOS on a modern PC with a PCIe 16550 controller, but won't stand a snowball in hell's chance of working with DOSBox. A bunch of companies use FreeDOS for precisely this reason.
It's not really new. A bunch of mainframe architectures were similar - proprietary, no compatibility provided when the company went out of business. The ones that people actually cared about grew emulators. I think you can run older versions of iOS in a modified QEMU (and Apple does internally, though they don't share their modified QEMU). Newer versions are probably harder, because I think Apple encrypts the firmware download with a per-device key, so you can't run someone else's firmware image on yours. That said, it only takes one person to crack the encryption (e.g. by exfiltrating the key from their device) and suddenly you have a download for everyone.
A 64-bit operating system, an archetype that is known widely by developers and IT to support both 32 and 64-bit, is now going to purposely block 32-bit when we all know it will work?
Not true. A 64-bit operating system running 32-bit binaries requires a compat version of the system call layer that handles the calling convention and pointer size differences (or some equivalent userspace shims). This is fairly easy to support for most system calls, but is impossible to automate for arbitrary ioctls and so they all end up needing special handling.
I have tried to tell both Linux and Window$ communities either here or on Reddit a while back about how 64-bit was nothing more than a tactic to get people to buy new hardware
And apparently you didn't listen to any of the answers. Here are some of the advantages that 64-bit binaries have on x86, for example:
Guaranteed SSE support, so no need to use x87 for any floating point stuff.
16 GPRs instead of 6 (or 8, depending on how you count), so far more efficient code generation.
More SSE registers, so more efficient floating point and vector code.
64-bit integer registers, so 64-bit arithmetic only needs 1 register and not 2 for each operand (important for most crypto, compression, and so on routines)
RIP-relative addressing, giving far more efficient position-independent code (i.e. all of the stuff in.so files, and any position-independent executables [needed for ASLR to work well])
A far more sparse address space, so more bits of entropy for ASLR, making life much harder for attackers.
I suppose that you can argue that the only reason x86 vendors make better chips is to make people buy them, but generally I'm in favour of CPU vendors making better chips. The advantages of AArch64 vs AArch32 are smaller, but they're also there.
The rest of your post is too incoherent to respond to.
Can somebody explain why it's news now that they stop providing software for something, which more or less failed to get newest software for 6 years already?
This isn't about stopping shipping software for 32-bit processors, it's stopping shipping the 32-bit compatibility layer for 64-bit operating systems on 64-bit processors.
That would be like having an Android phone that came with Android Jelly Bean, that could be upgraded all up to Android Nougat, and all that with firmware/upgrades pushed by Samsung itself.
The last part of that is the key. My phone came with Jelly Bean and now happily runs Nougat, but the Marshmallow and Nougat upgrades were third party (and required unlocking the bootloader and reflashing). Of course, the flip side of this is that my Android phone still gets OS updates after the original vendor decided to stop...
For first party support, yes. For third-party support, no. I have a first-generation Moto G (yes, I am a cheapskate). It was released in 2013 and I bought it in March 2014. Google spun off the bit of Motorola that they owned shortly after that and it got OS updates to Android 5.1.1 (released November 2014, available for the Moto G some time in early 2015) and then (horribly late) security updates for another year. The last security update for it was early 2016 and fixing a couple of high-profile vulnerabilities took Motorola about 4-6 months each. That's a pretty piss-poor support track record. That said, it now runs LineageOS and gets frequent and regular updates and is running Android 7.1.2.
If I'd bought an iPhone released at about the same time, it would have been a 5S or 5C and would have been updated until iOS 10. I'd have received first-party OS support until earlier this year and security back-ports probably for another year, but at the end of that I'd have a device that no one could provide third-party support for and which would be effectively worthless.
Theres a lot of coders that'll need to scramble to get their stuff off carbon and onto cocoa
Really? I just had a look, and I do have one 32-bit apps installed: Diablo II (which Blizzard released an update for a few years back to let it run on recent Mac versions, and which was originally a Mac Classic PowerPC app with post-release OS X and x86 support updates). Everything else is 64-bit and has been for ages. Carbon was basically killed around 10.6, when Apple announced that it was no longer supported for new applications and started killing off the Carbon templates in XCode. When they announced the death of Carbon, there were almost no complaints, and that was a decade ago.
The health effects of alcohol are unproven. A long-term study with a few tens of thousands of participants was reported on Slashdot a couple of years back that showed that, statistically, the people who died first are the ones that give up drinking, then the ones that never drink. The ones that regularly drink alcohol live longest. Alcohol in the blood stream dissolves fatty deposits in blood vessels and reduces the risk of blood clots blocking them, for example. The risk is nowhere near as simple as you seem to think.
I don't know, I'd be in favour of moving the UK somewhere a bit closer to the equator and improving the weather. Maybe we could park it just off the coast of Portugal?
It isn't much of a thing. The version distributed via the Apple App Store doesn't have any of the GPL'd bits, which includes things like the DVD menu support. You use dvdbackup to take a CSS-free copy of a DVD and play it fine on any version of VLC except the iOS one.
Depends. If you can generate C from your language, generating LLVM IR is almost always easier. The portability problems usually come from things like assuming word sizes, non-portable runtime library functions (either making non-portable assumptions, or relying on OS functionality that's not widely available) and so on.
Which shows a bit how broken our country is. The opposition leader was shouted down by most of the press for having the temerity to suggest that bombing random stuff isn't the solution to all foreign policy problems and that maybe nuclear weapons aren't actually that useful in massively asymmetric conflicts.
It looks like there's a good chance that Theresa May will be gone whatever the outcome of the election. Her personal approval is now lower than it's ever been and noticeably lower than the Tory party in general. If she doesn't doesn't deliver an increased Tory majority then expect the knives to come out.
Unfortunately, getopt doesn't really handle those cases well. For simple cases, I much prefer the OpenStep mechanism, where every option is inserted automatically into the user defaults dictionary. For more complex ones, see something like clang's options parser.
Not sure about the more recent versions, but in the original Quake this was for portability. The developed the game on UNIX workstations (not sure if they were still using NeXT m68k machines then) and originally shipped it for x86, but this bytecode meant that the same mods worked on x86, PowerPC, and any other architecture that you wanted to run them on. I remember playing the Mac port of GLQuake and being very pleased to discover that all of the mods that I'd collected on DOS still worked fine (though the game did cache some generated geometry files in native byte order mode, so you got completely messed up rendering if you didn't delete them!).
He seems to want to take a dataflow programming language and generate C from it. This is trivial and there have been a bunch of tools that do it. The problem is, it's entirely pointless. If your code is better represented as a flow chart, then use a dataflow programming language and don't bother with C as an intermediate representation. The only reason to turn it into C is if some parts of it are easier to edit as C code (typically, bits with complex flow control, because even nested loops in graphical dataflow languages are pretty hideous). Then the problem that you actually want to solve is turning a flow chart into C, editing it, and then turning it back again while preserving the original structure. This is much harder, but typically dataflow languages let you call out to C for complex operations and that's generally a better solution.
The legal and economic definitions of a monopoly are different (in the US as well as the EU). A monopoly in the economic sense is a single supplier for whom there is no competition, which can therefore exert massive influence over the market. A monopoly in the legal sense is a company with a sufficiently large market share that they can act as if they were a monopoly. In the EU, Google has over 90% of the search engine market. This means that, in terms of economic impact, the other players are largely irrelevant. If Google searches are rigged to push Google products, then this will affect almost as many consumers as if they had a monopoly in the traditional economic sense and will have the same impact on the market.
This is exactly the same situation that Microsoft was in with Windows. They didn't have 100% of the desktop market, but they had a large enough share that the remaining players between them had basically no impact on the market.
I can't speak for the grandparent, but the biggest dent to online music piracy came when the big four started letting online music stores sell DRM-free audio files. Suddenly, you could but a product that you wanted and guarantee that it would work on every device. The big four did this for a couple of reasons, but the main one was that they'd realised that DRM takes negotiating power from them and gives it to the DRM author or the channel. If you wanted DRM'd music to play on the large installed base of iPods, you needed to accept Apple's terms. If you didn't, then your potential customers would feel justified in piracy because you weren't offering the product in a form that worked with their hardware.
Eventually the movie companies will work this out. Amazon, Netflix, and Google spend a lot of money ensuring that set-top boxes and so on can play their DRM'd streams. Want to reach these potential customers? Either provide DRM-free content, or accept whatever terms these companies offer.
The argument boiled down to locking up pot heads is a waste of money. None of them hurt anyone else, the vast majority held stable jobs and the cost of locking them up was bankrupting the state so even if the state made no money from tax revenue it would still be a huge net win.
Note that the authoritarian counter argument to that would be that you could make it revenue positive by fining them rather than incarcerating them. Give everyone caught for possession a choice of an on-the-spot $50 fine or a federal prosecution and money will flow into the state coffers. Plus, you can withdraw the offer of the fine from anyone who seems inconvenient to the state.
Slashdot Mirror
Do you remember why AWS exists? Amazon had to have enough servers to handle peak buying times, but most of the time a load of them were sitting idle. They realised that they could make money by selling the idle cycles. The cost of this spare time to Amazon is a lot less than the cost of buying, powering, cooling, and connecting a machine would be to you. Google works the same way: their attitude to power management is that the machines should be running at 100% load all of the time, and if they aren't then you bought too many of them.
It wasn't always. The founders cared a lot about privacy and had a reasonable business model (free for the first year, $1 for each year after that. The servers were FreeBSD boxes running an Erlang stack and so the server cost per user was well under $1/year). Then Facebook bought them and it all went downhill.
Arguably our #1 killer right now is cardiovascular heart disease
And moderate alcohol intake has been shown to reduce this risk. Did you have a point somewhere, or are you just on a puritan rant?
The post said that it was a problem with DOSBox interacting with the hardware. DOSBox emulates some hardware, but doesn't allow direct access to the underlying hardware for anything running in the emulator. Access to serial and parallel ports more or less works for common uses, but for anything else it doesn't work (see the DOSBox documentation section about why you probably won't be able to get printing working). In contrast, FreeDOS provides the same abstractions as MS-DOS (i.e. very few) and permits direct access to the hardware. Stuff that needs to poke the serial UART directly with realtime timing constraints will work fine with FreeDOS on a modern PC with a PCIe 16550 controller, but won't stand a snowball in hell's chance of working with DOSBox. A bunch of companies use FreeDOS for precisely this reason.
It's not really new. A bunch of mainframe architectures were similar - proprietary, no compatibility provided when the company went out of business. The ones that people actually cared about grew emulators. I think you can run older versions of iOS in a modified QEMU (and Apple does internally, though they don't share their modified QEMU). Newer versions are probably harder, because I think Apple encrypts the firmware download with a per-device key, so you can't run someone else's firmware image on yours. That said, it only takes one person to crack the encryption (e.g. by exfiltrating the key from their device) and suddenly you have a download for everyone.
A 64-bit operating system, an archetype that is known widely by developers and IT to support both 32 and 64-bit, is now going to purposely block 32-bit when we all know it will work?
Not true. A 64-bit operating system running 32-bit binaries requires a compat version of the system call layer that handles the calling convention and pointer size differences (or some equivalent userspace shims). This is fairly easy to support for most system calls, but is impossible to automate for arbitrary ioctls and so they all end up needing special handling.
I have tried to tell both Linux and Window$ communities either here or on Reddit a while back about how 64-bit was nothing more than a tactic to get people to buy new hardware
And apparently you didn't listen to any of the answers. Here are some of the advantages that 64-bit binaries have on x86, for example:
I suppose that you can argue that the only reason x86 vendors make better chips is to make people buy them, but generally I'm in favour of CPU vendors making better chips. The advantages of AArch64 vs AArch32 are smaller, but they're also there.
The rest of your post is too incoherent to respond to.
Can somebody explain why it's news now that they stop providing software for something, which more or less failed to get newest software for 6 years already?
This isn't about stopping shipping software for 32-bit processors, it's stopping shipping the 32-bit compatibility layer for 64-bit operating systems on 64-bit processors.
That would be like having an Android phone that came with Android Jelly Bean, that could be upgraded all up to Android Nougat, and all that with firmware/upgrades pushed by Samsung itself.
The last part of that is the key. My phone came with Jelly Bean and now happily runs Nougat, but the Marshmallow and Nougat upgrades were third party (and required unlocking the bootloader and reflashing). Of course, the flip side of this is that my Android phone still gets OS updates after the original vendor decided to stop...
For first party support, yes. For third-party support, no. I have a first-generation Moto G (yes, I am a cheapskate). It was released in 2013 and I bought it in March 2014. Google spun off the bit of Motorola that they owned shortly after that and it got OS updates to Android 5.1.1 (released November 2014, available for the Moto G some time in early 2015) and then (horribly late) security updates for another year. The last security update for it was early 2016 and fixing a couple of high-profile vulnerabilities took Motorola about 4-6 months each. That's a pretty piss-poor support track record. That said, it now runs LineageOS and gets frequent and regular updates and is running Android 7.1.2.
If I'd bought an iPhone released at about the same time, it would have been a 5S or 5C and would have been updated until iOS 10. I'd have received first-party OS support until earlier this year and security back-ports probably for another year, but at the end of that I'd have a device that no one could provide third-party support for and which would be effectively worthless.
You thought wrong, and if you thought for a few seconds more, you'd realise why what you're describing would be a terrible idea.
FreeDOS works on modern hardware and will run most of this kind of thing.
Theres a lot of coders that'll need to scramble to get their stuff off carbon and onto cocoa
Really? I just had a look, and I do have one 32-bit apps installed: Diablo II (which Blizzard released an update for a few years back to let it run on recent Mac versions, and which was originally a Mac Classic PowerPC app with post-release OS X and x86 support updates). Everything else is 64-bit and has been for ages. Carbon was basically killed around 10.6, when Apple announced that it was no longer supported for new applications and started killing off the Carbon templates in XCode. When they announced the death of Carbon, there were almost no complaints, and that was a decade ago.
The health effects of alcohol are unproven. A long-term study with a few tens of thousands of participants was reported on Slashdot a couple of years back that showed that, statistically, the people who died first are the ones that give up drinking, then the ones that never drink. The ones that regularly drink alcohol live longest. Alcohol in the blood stream dissolves fatty deposits in blood vessels and reduces the risk of blood clots blocking them, for example. The risk is nowhere near as simple as you seem to think.
I don't know, I'd be in favour of moving the UK somewhere a bit closer to the equator and improving the weather. Maybe we could park it just off the coast of Portugal?
It isn't much of a thing. The version distributed via the Apple App Store doesn't have any of the GPL'd bits, which includes things like the DVD menu support. You use dvdbackup to take a CSS-free copy of a DVD and play it fine on any version of VLC except the iOS one.
Depends. If you can generate C from your language, generating LLVM IR is almost always easier. The portability problems usually come from things like assuming word sizes, non-portable runtime library functions (either making non-portable assumptions, or relying on OS functionality that's not widely available) and so on.
Which shows a bit how broken our country is. The opposition leader was shouted down by most of the press for having the temerity to suggest that bombing random stuff isn't the solution to all foreign policy problems and that maybe nuclear weapons aren't actually that useful in massively asymmetric conflicts.
It looks like there's a good chance that Theresa May will be gone whatever the outcome of the election. Her personal approval is now lower than it's ever been and noticeably lower than the Tory party in general. If she doesn't doesn't deliver an increased Tory majority then expect the knives to come out.
Unfortunately, getopt doesn't really handle those cases well. For simple cases, I much prefer the OpenStep mechanism, where every option is inserted automatically into the user defaults dictionary. For more complex ones, see something like clang's options parser.
Not sure about the more recent versions, but in the original Quake this was for portability. The developed the game on UNIX workstations (not sure if they were still using NeXT m68k machines then) and originally shipped it for x86, but this bytecode meant that the same mods worked on x86, PowerPC, and any other architecture that you wanted to run them on. I remember playing the Mac port of GLQuake and being very pleased to discover that all of the mods that I'd collected on DOS still worked fine (though the game did cache some generated geometry files in native byte order mode, so you got completely messed up rendering if you didn't delete them!).
Copy protection is a subset of DRM. DRM also restricts how you can use the media, not just whether you can copy it.
He seems to want to take a dataflow programming language and generate C from it. This is trivial and there have been a bunch of tools that do it. The problem is, it's entirely pointless. If your code is better represented as a flow chart, then use a dataflow programming language and don't bother with C as an intermediate representation. The only reason to turn it into C is if some parts of it are easier to edit as C code (typically, bits with complex flow control, because even nested loops in graphical dataflow languages are pretty hideous). Then the problem that you actually want to solve is turning a flow chart into C, editing it, and then turning it back again while preserving the original structure. This is much harder, but typically dataflow languages let you call out to C for complex operations and that's generally a better solution.
The legal and economic definitions of a monopoly are different (in the US as well as the EU). A monopoly in the economic sense is a single supplier for whom there is no competition, which can therefore exert massive influence over the market. A monopoly in the legal sense is a company with a sufficiently large market share that they can act as if they were a monopoly. In the EU, Google has over 90% of the search engine market. This means that, in terms of economic impact, the other players are largely irrelevant. If Google searches are rigged to push Google products, then this will affect almost as many consumers as if they had a monopoly in the traditional economic sense and will have the same impact on the market.
This is exactly the same situation that Microsoft was in with Windows. They didn't have 100% of the desktop market, but they had a large enough share that the remaining players between them had basically no impact on the market.
I can't speak for the grandparent, but the biggest dent to online music piracy came when the big four started letting online music stores sell DRM-free audio files. Suddenly, you could but a product that you wanted and guarantee that it would work on every device. The big four did this for a couple of reasons, but the main one was that they'd realised that DRM takes negotiating power from them and gives it to the DRM author or the channel. If you wanted DRM'd music to play on the large installed base of iPods, you needed to accept Apple's terms. If you didn't, then your potential customers would feel justified in piracy because you weren't offering the product in a form that worked with their hardware.
Eventually the movie companies will work this out. Amazon, Netflix, and Google spend a lot of money ensuring that set-top boxes and so on can play their DRM'd streams. Want to reach these potential customers? Either provide DRM-free content, or accept whatever terms these companies offer.
The argument boiled down to locking up pot heads is a waste of money. None of them hurt anyone else, the vast majority held stable jobs and the cost of locking them up was bankrupting the state so even if the state made no money from tax revenue it would still be a huge net win.
Note that the authoritarian counter argument to that would be that you could make it revenue positive by fining them rather than incarcerating them. Give everyone caught for possession a choice of an on-the-spot $50 fine or a federal prosecution and money will flow into the state coffers. Plus, you can withdraw the offer of the fine from anyone who seems inconvenient to the state.