Problem with VLIW was that each new CPU was guaranteed to break backwards compatibility,
Only if you do it in a way that either 1) changes the instruction encoding from CPU to CPU or 2) doesn't have rules for code that's guaranteed to work on all future processors. The IA-64 documentation gives the instruction encoding for all processors, and does have rules of that sort (see, for example, section 3.4 "Instruction Sequencing Considerations"), so they didn't do it in one of those ways, so each CPU is guaranteed not to break backwards compatibility for valid code (which means that the code doesn't, for example, have any of the dependencies that are "not allowed" by section 3.4).
That actually assumes that Intel can't add new instructions to future versions of the Itanium that may not have been anticipated during the work on Merced. I wasn't assuming that opcodes would change, just that new ones would be introduced that might improve, say, loop unrolling, and that to make use of that, the VLIW compiler would have to kick in. Like if the number of registers in a subsequent generation CPUs is increased, and register renaming is in the hands of the compiler, recompilation would automatically be required to get any performance enhancement, or worse, prevent a performance degradation.
That's a bit more than what happens with every other type of CPU, but not all that much more - new instructions are added, and some instruction sets even acquired more registers (z/Architecture added some instructions to manipulate the lower half and upper half of registers, so that a single 64-bit GPR can act as 2 32-bit GPRs, for example).
But that doesn't break binary compatibility, it just requires recompilation for more performance. If not recompiling causes a significant performance hit, that's a severe problem, though.
(And the recompilation would happen transparently, other than some first-time performance hit, on a {System/38,AS/400,IBM i}-style system, where compilers generate a higher-level code that gets translated to executable machine code when the code is first executed, allowing a re-translation the first time the code is executed on a new machine. That's also kinda sorta what Transmeta did. But most systems aren't like that, for better or worse.)
What finally killed both RISC and EPIC was not x86 itself, but the multi core architecture that Intel packed into its way advanced processes. Once Microsoft united the Windows code bases in XP, making SMP support standard on all Windows, Intel could toss in more cores to boost performance, and totally negate the performance advantages of the PA-RISC, Alpha and everyone else.
I had the impression that, at least for the desktop and small server market, they lost a lot of that performance advantage well before Intel went multi-core.
That might have been the case with the Pentium 4, but then it had some serious issues, such as power consumption, that hampered its market acceptance.
I seem to remember seeing claims (in Microprocessor Report?) that x86 was giving the faster RISCs a run for their money in the P6 days, even if it wasn't quite doing completely as well or better.
Problem with VLIW was that each new CPU was guaranteed to break backwards compatibility,
Only if you do it in a way that either 1) changes the instruction encoding from CPU to CPU or 2) doesn't have rules for code that's guaranteed to work on all future processors. The IA-64 documentation gives the instruction encoding for all processors, and does have rules of that sort (see, for example, section 3.4 "Instruction Sequencing Considerations"), so they didn't do it in one of those ways, so each CPU is guaranteed not to break backwards compatibility for valid code (which means that the code doesn't, for example, have any of the dependencies that are "not allowed" by section 3.4).
therefore forcing ISVs to recompile every time. Great for performance, maybe, but horrendous as a market acceptance strategy.
Except that you don't have to recompile code to have it run on a future Itanium processor, as long as the compiler wasn't "too clever", generating code with "not allowed" dependencies because it "knew" that the processor would execute that code in the way it intended.
You might get performance improvements by recompiling for a new processor, but that's hardly unique to Itanium.
What finally killed both RISC and EPIC was not x86 itself, but the multi core architecture that Intel packed into its way advanced processes. Once Microsoft united the Windows code bases in XP, making SMP support standard on all Windows, Intel could toss in more cores to boost performance, and totally negate the performance advantages of the PA-RISC, Alpha and everyone else.
I had the impression that, at least for the desktop and small server market, they lost a lot of that performance advantage well before Intel went multi-core.
If so, could you cite some papers indicating that, for example, the SPARC M7, or the POWER8, or the Itanium 9500, have microcode in that sense?
It probably does not apply to SPARC, I am fairly certain that there is microcode involved at minimum in some POWER processor coprocessors but can't find a reference, there is absolutely microcode in Itanium and Intel has used it to fix errors.
There's firmware, but it's not clear from what Intel says there that it's "microcode" in the conventional sense, as opposed to low-level Itanium instruction set (the instruction set formerly known as IA-64) code.
And during those times workstations were Sun, HP, DEC, etc.
All of which also built x86 Unix systems and sold Unix for x86 PC clones.
Sun did, when they made the Sun386i running SunOS 4.0.x; it wasn't a big success (and wasn't PC-compatible). HP and DEC made PCs, but didn't port their own UNIXes to them, and so obviously neither ran HP-UX nor Ultrix nor Digital UNIX on them nor sold HP-UX nor Ultrix nor Digital UNIX for other people's PCs.
You're also conspicuously leaving out IBM, which also made PCs and Unix for PCs and even something weird and in between, the IBM PC/RT; on which you could run AIX or BSD. It had an ISA bus and the most fancy-pants model had a whoppin' 16MB RAM.
...and a non-x86 processor (and it was the "IBM RT PC", not the "IBM PC/RT").
I infer from IBM's use of "micro-operation" in papers about recent z/Architecture processors that it's also true of z/Architecture.
IBM is huge on microcode,
So I guess they abandoned that whole silly "801" "RISC" project when they found it didn't have any microcode. Good thing they did, or they'd have ended up with a line of RISC processors.
I presume that POWER itself when implemented for RS6k has about a normal amount of microcode; I know there is some.
And how do you know this?
Last I looked, AS/400 systems even when they were still being called that were being implemented as a wrapper around POWER or even PowerPC, depending on model.
Soltis says this was done because IBM were worried that they might be forced to sell their OS software for use on compatible hardware, and they wanted to make sure that didn't happen with System/38, so they put the development of the low-level OS and binary-to-binary translation code under a hardware manager, and called it "vertical microcode", so they could claim it wasn't system software and didn't have to be unbundled.
That continued with AS/400 - which allowed them to replace the old CISC instruction set with an extended PowerPC instruction set without breaking binary compatibility - the OS would just retranslate the MI instructions to PowerPC code and run that. (The result of the translation are cached on disk along with the "source" MI code; apparently, AS/400 allowed the "source" code to be discarded, presumably to save disk space, and if you did that, you'd have a problem switching to the RISC machines.)
And AFAIK that is basically true of all their hardware now, it's all POWER-based at some level.
Nope, the z/Architecture microprocessors natively run the z/Architecture instruction set; the designers of the z/Architecture and POWER chips might talk to each other and use some hardware in common, but the z/Architecture CPUs are not POWER-based.
If it ain't broke, don't break it by trying to fix it. When HP decided that Itanium was the way forward, that was "HP-UX on Itanium" for their machines, so they didn't "[decide] HP-UX was yesterdays news" at that point.
Cheap commodity hardware from China is cheap commodity hardware from China regardless of who you buy it from. It's all ODM as none of the big IT consulting firms designs their own hardware anymore. It's all re-branded SuperMicro or Intel reference designs.
I.e., all the HP Integrity system boards, including the Itanium-based ones, are Intel reference designs?
(Obviously, neither Oracle's SPARC machines, nor IBM's Power ISA or z/Architecture machines, are based on Intel reference designs, as Intel don't make SPARC, POWER, or z/Architecture processors.)
(I'm ruling SuperMicro out here, as I rather doubt they make any Itanium, SPARC, Power ISA, or z/Architecture boards.)
I agree. There was a time when workstation meant a computer used for technical/business stuff, and a PC was a "toy". And during those times workstations were Sun, HP, DEC, etc. I remember using HP-UX machines with "unheard" amounts of RAM (128MB), while a typical PC was still playing games with Expanded vs Extended memory in DOS, typically 4 or 8MB maximum RAM. Linux was not a thing yet. PC's could run Windows 3, but "real" work which needed a Unix workstation meant, Sun, HP, IBM or DEC.
...the first of which had an, admittedly unsuccessful, 386-based workstation (along with their 68k and SPARC-based workstations).
As all the RISC CPUs migrated to IA-64,
They didn't. Only PA-RISC did.
and then got beat by x86-64, there was also the movement away from the different Unices (HP-UX, Solaris, VMS, etc.) to Linux.
Presumably you meant "(HP-UX, Solaris, AIX, etc.)"; VMS wasn't a UNIX, but AIX is one of the three remaining Big Server Commercial UNIXes, along with HP-UX and Solaris.
It was the combination of x86-64 performance and cost improvements coupled with the explosion of Linux on PC hardware
...and the availability of 32-bit and later 64-bit Windows, and of versions of traditional "engineering workstation" software for Windows, so that you no longer needed a traditional commercial UNIX running on a RISC-based workstation.
If the compiler had more valuable insight into low-level instruction ordering than the actual CPU itself does, then the Itanium would not have been such an epic failure.
Perhaps leaving all instruction scheduling up to the compiler, as with Itanium, was harder than having the compiler schedule instructions (as is done by many compilers, including x86 compilers) and then having the processor reorder them (as is done on RISC processors) or chop them into micro-ops and recording them (as is done on x86 and z/Architecture processors).
The processor core is RISC-like, and x86 instructions are decomposed into series of micro-ops before actually being executed. This has been true of AMD since the Am586 and of Intel since the Pentium.
Pentium Pro, not Pentium.
I infer from IBM's use of "micro-operation" in papers about recent z/Architecture processors that it's also true of z/Architecture. (BTW, two of the first implementations of the System/360 ancestor of z/Architecture, the System/360 Models 75 and 91/95, implemented the instruction set entirely in hardwired logic rather than microcode; the other models used microcode.)
And all modern processors of any complexity have microcode, and you have no idea how much.
What do you mean by "microcode" here? Do you mean it in the traditional sense, wherein the CPU's instruction-execution state machine is implemented as a set of microinstructions? If so, could you cite some papers indicating that, for example, the SPARC M7, or the POWER8, or the Itanium 9500, have microcode in that sense?
It'll probably cost double what the Echo does, and you'll have to buy a new one once a year.
Yes, because every single Apple machine turns into a pile of dust one year after it's bought.
You might choose to buy a new one every year because you get excited by the Apple event where the new one is introduced, but you don't have to do that. (I have to buy a new iPhone this year, but that's because next year it becomes an iPod touch with an extra useless radio. It still works, and is actually still mostly usable on the Intertubes.)
We should make an islamic instagram app that automatically superimposes hijab/niqab on all females in a given shot. Hek it just removes all females from pics
anyone born between 20 and 30 years ago are completely screwed due to lead decreasing their mental faculties. Thanks to all the god damn baby boomers for putting that garbage in everything.
Tetraethyl lead was first added to gasoline in the 1920's, over 40 years before the post-war baby boom. It started to be phased out in the 1970's.
Lead-based pain existed long before the baby boom, and it, too, started to be phased out in the 1970's.
It doesn't say anything about 32 bit or i686 in the headline.
Just says older cpus.
And in the first line of the story it says "An anonymous reader shares DistroWatch's report that the Debian distribution will soon be dropping support for older, 32-bit processors." Perhaps the comma after "older" should have been left out, so that it was clear that it meant "those 32-bit processors that are older", as in "pre-P6", rather than "those older processors - you know, the 32-bit ones".
No it isn't. It is lightening your hard drive. Because it doesn't hold as much data anymore. It is now lighter.
If you had ever used punch cards, you would know that data has a negative mass.
1 bits have negative mass on punched cards.
On NAND flash (which many newer Macs are using as the "local disk"), at least if the Wikipedia page is to be believed, 0 bits have positive mass, as there's a charge stored in the cell.
Some of them might, but if for no other reason than this article, it is naive to think that a proper understanding of critical reasoning, verified facts, and perspective of the fundamental rules of the universe is sufficient to save us from emotional or non-logical decision making.
Yes, that's why I said "some of them might" - there are no guarantees there.
Slashdot Mirror
Problem with VLIW was that each new CPU was guaranteed to break backwards compatibility,
Only if you do it in a way that either 1) changes the instruction encoding from CPU to CPU or 2) doesn't have rules for code that's guaranteed to work on all future processors. The IA-64 documentation gives the instruction encoding for all processors, and does have rules of that sort (see, for example, section 3.4 "Instruction Sequencing Considerations"), so they didn't do it in one of those ways, so each CPU is guaranteed not to break backwards compatibility for valid code (which means that the code doesn't, for example, have any of the dependencies that are "not allowed" by section 3.4).
That actually assumes that Intel can't add new instructions to future versions of the Itanium that may not have been anticipated during the work on Merced. I wasn't assuming that opcodes would change, just that new ones would be introduced that might improve, say, loop unrolling, and that to make use of that, the VLIW compiler would have to kick in. Like if the number of registers in a subsequent generation CPUs is increased, and register renaming is in the hands of the compiler, recompilation would automatically be required to get any performance enhancement, or worse, prevent a performance degradation.
That's a bit more than what happens with every other type of CPU, but not all that much more - new instructions are added, and some instruction sets even acquired more registers (z/Architecture added some instructions to manipulate the lower half and upper half of registers, so that a single 64-bit GPR can act as 2 32-bit GPRs, for example).
But that doesn't break binary compatibility, it just requires recompilation for more performance. If not recompiling causes a significant performance hit, that's a severe problem, though.
(And the recompilation would happen transparently, other than some first-time performance hit, on a {System/38,AS/400,IBM i}-style system, where compilers generate a higher-level code that gets translated to executable machine code when the code is first executed, allowing a re-translation the first time the code is executed on a new machine. That's also kinda sorta what Transmeta did. But most systems aren't like that, for better or worse.)
What finally killed both RISC and EPIC was not x86 itself, but the multi core architecture that Intel packed into its way advanced processes. Once Microsoft united the Windows code bases in XP, making SMP support standard on all Windows, Intel could toss in more cores to boost performance, and totally negate the performance advantages of the PA-RISC, Alpha and everyone else.
I had the impression that, at least for the desktop and small server market, they lost a lot of that performance advantage well before Intel went multi-core.
That might have been the case with the Pentium 4, but then it had some serious issues, such as power consumption, that hampered its market acceptance.
I seem to remember seeing claims (in Microprocessor Report?) that x86 was giving the faster RISCs a run for their money in the P6 days, even if it wasn't quite doing completely as well or better.
Problem with VLIW was that each new CPU was guaranteed to break backwards compatibility,
Only if you do it in a way that either 1) changes the instruction encoding from CPU to CPU or 2) doesn't have rules for code that's guaranteed to work on all future processors. The IA-64 documentation gives the instruction encoding for all processors, and does have rules of that sort (see, for example, section 3.4 "Instruction Sequencing Considerations"), so they didn't do it in one of those ways, so each CPU is guaranteed not to break backwards compatibility for valid code (which means that the code doesn't, for example, have any of the dependencies that are "not allowed" by section 3.4).
therefore forcing ISVs to recompile every time. Great for performance, maybe, but horrendous as a market acceptance strategy.
Except that you don't have to recompile code to have it run on a future Itanium processor, as long as the compiler wasn't "too clever", generating code with "not allowed" dependencies because it "knew" that the processor would execute that code in the way it intended.
You might get performance improvements by recompiling for a new processor, but that's hardly unique to Itanium.
What finally killed both RISC and EPIC was not x86 itself, but the multi core architecture that Intel packed into its way advanced processes. Once Microsoft united the Windows code bases in XP, making SMP support standard on all Windows, Intel could toss in more cores to boost performance, and totally negate the performance advantages of the PA-RISC, Alpha and everyone else.
I had the impression that, at least for the desktop and small server market, they lost a lot of that performance advantage well before Intel went multi-core.
Pretty soon HP will be reduced to a company with some patents and selling printers.
So what will happen to HPE (which sells no printers)?
Here's the actual Government Accounting Office report, if you want to read it instead of a Slashdot story about a news story about the report.
So in the long term, would we see a return of first Compaq,
There's now a PC and printer company named "HP"; I'm not sure what form of spinoff would restore Compaq.
and then DEC?
Alpha's dead, so they'd either have to bring that back to life, or spin off the OpenVMS-on-Itanium part to bring DEC back.
If so, could you cite some papers indicating that, for example, the SPARC M7, or the POWER8, or the Itanium 9500, have microcode in that sense?
It probably does not apply to SPARC, I am fairly certain that there is microcode involved at minimum in some POWER processor coprocessors but can't find a reference, there is absolutely microcode in Itanium and Intel has used it to fix errors.
There's firmware , but it's not clear from what Intel says there that it's "microcode" in the conventional sense, as opposed to low-level Itanium instruction set (the instruction set formerly known as IA-64) code.
And during those times workstations were Sun, HP, DEC, etc.
All of which also built x86 Unix systems and sold Unix for x86 PC clones.
Sun did, when they made the Sun386i running SunOS 4.0.x; it wasn't a big success (and wasn't PC-compatible). HP and DEC made PCs, but didn't port their own UNIXes to them, and so obviously neither ran HP-UX nor Ultrix nor Digital UNIX on them nor sold HP-UX nor Ultrix nor Digital UNIX for other people's PCs.
You're also conspicuously leaving out IBM, which also made PCs and Unix for PCs and even something weird and in between, the IBM PC/RT; on which you could run AIX or BSD. It had an ISA bus and the most fancy-pants model had a whoppin' 16MB RAM.
...and a non-x86 processor (and it was the "IBM RT PC", not the "IBM PC/RT").
I infer from IBM's use of "micro-operation" in papers about recent z/Architecture processors that it's also true of z/Architecture.
IBM is huge on microcode,
So I guess they abandoned that whole silly "801" "RISC" project when they found it didn't have any microcode. Good thing they did, or they'd have ended up with a line of RISC processors.
I presume that POWER itself when implemented for RS6k has about a normal amount of microcode; I know there is some.
And how do you know this?
Last I looked, AS/400 systems even when they were still being called that were being implemented as a wrapper around POWER or even PowerPC, depending on model.
The predecessor to AS/400, System/38, was an interesting system. They had two layers that they referred to as "microcode" but, as Frank Soltis, one of the chief architects if not the chief architect, noted in one of his books on AS/400, that was a legal fiction for the higher level of "microcode". The underlying processor had a System/3x0-ish instruction set, implemented on a processor that used horizontal microcode to implement it. It then had something called "vertical microcode", made up of instructions in that System/3x0-ish instruction set, running from main memory. However, the uber-CISCy instruction set generated by compilers/a> doesn't get interpretively executed by the "vertical microcode"; instead, the "vertical microcode" translates the MI instructions into the same instruction set as the "vertical microcode" uses, and runs it from main memory as well.
Soltis says this was done because IBM were worried that they might be forced to sell their OS software for use on compatible hardware, and they wanted to make sure that didn't happen with System/38, so they put the development of the low-level OS and binary-to-binary translation code under a hardware manager, and called it "vertical microcode", so they could claim it wasn't system software and didn't have to be unbundled.
That continued with AS/400 - which allowed them to replace the old CISC instruction set with an extended PowerPC instruction set without breaking binary compatibility - the OS would just retranslate the MI instructions to PowerPC code and run that. (The result of the translation are cached on disk along with the "source" MI code; apparently, AS/400 allowed the "source" code to be discarded, presumably to save disk space, and if you did that, you'd have a problem switching to the RISC machines.)
And AFAIK that is basically true of all their hardware now, it's all POWER-based at some level.
Nope, the z/Architecture microprocessors natively run the z/Architecture instruction set; the designers of the z/Architecture and POWER chips might talk to each other and use some hardware in common, but the z/Architecture CPUs are not POWER-based.
s/x86/itanium
Fixed that for you
If it ain't broke, don't break it by trying to fix it. When HP decided that Itanium was the way forward, that was "HP-UX on Itanium" for their machines, so they didn't "[decide] HP-UX was yesterdays news" at that point.
Presumably by "decided HP-UX was yesterdays news and x86 was the way forward" the person whose statement you're "fixing" was referring to HP announcing Xeon-based Superdome servers not running HP-UX, and HP-UX not being ported to x86.
Cheap commodity hardware from China is cheap commodity hardware from China regardless of who you buy it from. It's all ODM as none of the big IT consulting firms designs their own hardware anymore. It's all re-branded SuperMicro or Intel reference designs.
I.e., all the HP Integrity system boards, including the Itanium-based ones, are Intel reference designs?
(Obviously, neither Oracle's SPARC machines, nor IBM's Power ISA or z/Architecture machines, are based on Intel reference designs, as Intel don't make SPARC, POWER, or z/Architecture processors.)
(I'm ruling SuperMicro out here, as I rather doubt they make any Itanium, SPARC, Power ISA, or z/Architecture boards.)
I agree. There was a time when workstation meant a computer used for technical/business stuff, and a PC was a "toy". And during those times workstations were Sun, HP, DEC, etc. I remember using HP-UX machines with "unheard" amounts of RAM (128MB), while a typical PC was still playing games with Expanded vs Extended memory in DOS, typically 4 or 8MB maximum RAM. Linux was not a thing yet. PC's could run Windows 3, but "real" work which needed a Unix workstation meant, Sun, HP, IBM or DEC.
...the first of which had an, admittedly unsuccessful, 386-based workstation (along with their 68k and SPARC-based workstations).
As all the RISC CPUs migrated to IA-64,
They didn't. Only PA-RISC did.
and then got beat by x86-64, there was also the movement away from the different Unices (HP-UX, Solaris, VMS, etc.) to Linux.
Presumably you meant "(HP-UX, Solaris, AIX, etc.)"; VMS wasn't a UNIX, but AIX is one of the three remaining Big Server Commercial UNIXes, along with HP-UX and Solaris.
It was the combination of x86-64 performance and cost improvements coupled with the explosion of Linux on PC hardware
...and the availability of 32-bit and later 64-bit Windows, and of versions of traditional "engineering workstation" software for Windows, so that you no longer needed a traditional commercial UNIX running on a RISC-based workstation.
If the compiler had more valuable insight into low-level instruction ordering than the actual CPU itself does, then the Itanium would not have been such an epic failure.
Perhaps leaving all instruction scheduling up to the compiler, as with Itanium, was harder than having the compiler schedule instructions (as is done by many compilers, including x86 compilers) and then having the processor reorder them (as is done on RISC processors) or chop them into micro-ops and recording them (as is done on x86 and z/Architecture processors).
The processor core is RISC-like, and x86 instructions are decomposed into series of micro-ops before actually being executed. This has been true of AMD since the Am586 and of Intel since the Pentium.
Pentium Pro, not Pentium.
I infer from IBM's use of "micro-operation" in papers about recent z/Architecture processors that it's also true of z/Architecture. (BTW, two of the first implementations of the System/360 ancestor of z/Architecture, the System/360 Models 75 and 91/95, implemented the instruction set entirely in hardwired logic rather than microcode; the other models used microcode.)
And all modern processors of any complexity have microcode, and you have no idea how much.
What do you mean by "microcode" here? Do you mean it in the traditional sense, wherein the CPU's instruction-execution state machine is implemented as a set of microinstructions? If so, could you cite some papers indicating that, for example, the SPARC M7, or the POWER8, or the Itanium 9500, have microcode in that sense?
This is the start of the "Hey we have that too" reaction to product RND
You mean like they did with that failed MP3 player of theirs? What was it called the iMP3 or something?
I see you refrained from using either the word "Nomad" or the word "lame". :-)
It'll probably cost double what the Echo does, and you'll have to buy a new one once a year.
Yes, because every single Apple machine turns into a pile of dust one year after it's bought.
You might choose to buy a new one every year because you get excited by the Apple event where the new one is introduced, but you don't have to do that. (I have to buy a new iPhone this year, but that's because next year it becomes an iPod touch with an extra useless radio. It still works, and is actually still mostly usable on the Intertubes.)
"Seeing a Segway in the wild is akin to spotting a unicorn galloping down the street." ---- This right here
I live in an area where Bentley's and Ferrari's are quite common but have only see 1 Segway in public this decade.
I live in an area where Bentleys and Ferraris are not uncommon - heck, I even saw a McLaren on the road a few days ago, and I've seen probably about 5-7 Segways over the past decade. Unicorns, these days, on the other hand....
We should make an islamic instagram app that automatically superimposes hijab/niqab on all females in a given shot. Hek it just removes all females from pics
There would be multiple markets for that app.
anyone born between 20 and 30 years ago are completely screwed due to lead decreasing their mental faculties. Thanks to all the god damn baby boomers for putting that garbage in everything.
Tetraethyl lead was first added to gasoline in the 1920's, over 40 years before the post-war baby boom. It started to be phased out in the 1970's.
Lead-based pain existed long before the baby boom, and it, too, started to be phased out in the 1970's.
i can see dropping 386/486 as they where 30 years old but there still is tons and tons of 32 bit devices in the wiled.
Yeah, like devices with Pentium {Pro,II,III,4}. Those aren't being dropped.
Debian Dropping Support For Older CPUs
It doesn't say anything about 32 bit or i686 in the headline. Just says older cpus.
And in the first line of the story it says "An anonymous reader shares DistroWatch's report that the Debian distribution will soon be dropping support for older, 32-bit processors." Perhaps the comma after "older" should have been left out, so that it was clear that it meant "those 32-bit processors that are older", as in "pre-P6", rather than "those older processors - you know, the 32-bit ones".
No it isn't. It is lightening your hard drive. Because it doesn't hold as much data anymore. It is now lighter.
If you had ever used punch cards, you would know that data has a negative mass.
1 bits have negative mass on punched cards.
On NAND flash (which many newer Macs are using as the "local disk"), at least if the Wikipedia page is to be believed, 0 bits have positive mass, as there's a charge stored in the cell.
Psst! you forgot the "-r"
That's only necessary if you want to remove directories from the local disk.
(But if you want to remove files with more than one character in the name, you probably want rm -f * rather than rm -f ?. :-))
Any AI worth its salt would realize that's not realistic.
On the other hand, any AI worth its salt would not have rejected that script merely because of its scientific absurdity.
A good AI might have tossed out the sequels, however.
Some of them might, but if for no other reason than this article, it is naive to think that a proper understanding of critical reasoning, verified facts, and perspective of the fundamental rules of the universe is sufficient to save us from emotional or non-logical decision making.
Yes, that's why I said "some of them might" - there are no guarantees there.