I think Belial6 is talking out of his ass. However, there was a time when games would be delivered in a couple of versions, a DOS version and the Windows (95) version. The DOS version usually outperformed the Windows version, but often for technical reasons that didn't actually involve Windows at all. An example would be Descent II. The Windows version performed just fine when fullscreened, but if you ran it windowed there was a performance impact. It isn't all that surprising, considering Windows was emulating a DOS console.
Although, as Hatta pointed out, slashcode ate his less than symbol, you're still incorrect. "skein [args] FILE" would only make argv[argc-1]="FILE" not the zeroth file descriptor (stdin) equal to "FILE", which is necessary if "echo FILE | skein [args]" and "skein [args] FILE" are to agree. If such a program was made to hash the last argument you'd have to go through a heck of a lot of work escaping your file contents and trying to avoid the maximum argument length.
So what you're saying is that YOU were unaware of the industry-specific oft used phrase "cattle call" and the other phrases, equally demeaning, are okay because some pop culture icons have used them publicly.
When virtual reality is possible, the student can learn history by "being there".
They can learn what an artist's version of history is. This can probably be done better than the standard textbooks, but it also makes rewriting history easier and more real than the truth written in some book.
Your Scheme-in-one-defun, did is support a standard such as R5RS or R6RS? If not, then you're not making a fair comparison between it and Guile. There are valid reasons for that extra code, not just because the FSF adds needless code to every project.
Although correct, that depends on an exploit to some programming error such as an unchecked buffer access. Programs (and therefore parsers) can be written in such a way that lends itself to automated correctness checking. But, when you permit executable objects to be embedded within your data format, there simply is no way to prove correctness. There are some strategies to limit system exposure to these embedded objects, but as we have seen before, they often leak information or have security vulnerabilities.
TFA does a fine job of demonstrating how passing control to an embedded executable object (Flash) leads to a situation where Microsoft Word, which normally provides warning, fails to inform the user of the potential threat.
Without the dumb effects that made that game so dark (hard to view), the Voodoo 2 makes game looks a lot more fun! Reminds me a bit of the original HalfLife.
Could you explain your reasoning more? I'm not seeing how parsing an ASCII text file or similar static document necessarily means there's a hole to be exploited. Besides, there are numerous documents that are purely descriptive in nature without depending on render time execution.
Also, quit spouting your "feelings" on the issue when it doesn't match up with facts.
"Anti-intellectualism has been a constant thread winding its way through our political and cultural life, nurtured by the false notion that democracy means that 'my ignorance is just as good as your knowledge.'"
-- Isaac Asimov
This is why they had to wait for shipped rad-hardened robots.
Is there any evidence that the robots their using, iRobot PackBots, are radiation hardened? I am yet to see any. It seems to me that they were simply unprepared for the situation.
See each of those mach-* and plat-* directories? Each of those are major architectural variants which use the ARM Instruction Set Architecture for their CPU.
But, to see where the problem really lies let's dig deeper. Let's select a popular architecture, the Texas Instruments OMAP2, also shared by the OMAP3 and OMAP4 series.
See all of those board-* files? Each of those represents a specific implementation of the OMAP2+ architecture. The rest of the files are support for the underlying functionality exposed by these board files.
You see, this is a mess. The current state is akin to having each variant of X86 with its own file. E.g. an architecture directory for each PC manufacturer (IBM, Dell, HP, Compaq, Lenovo, etc) and then in each directory the variant implementation files (Lenovo X40, X41, T40, T60, T60p; Compaq Presario CQ50, CQ56, CQ62 and so on). Whenever you change an underlying subsystem used by many boards, such as USB or Flash, you have to visit each of these architectures and boards and update them.
The reason for the mess in ARM is that ARM is the CPU core, an ISA, that's all. Beyond that it is completely nonstandard. Memory locations, flash interfaces, Serial Peripheral Interface (SPI), Two-Wire Interfaces (I2C), USB controllers and numerous other hardware configurations are all chip specific. The PC has standardized these using the BIOS, EFI, PCI and other industry wide standards. Sure you'll need drivers to use the devices, but at least you can boot up and detect them. From there it is simply a matter of loading the module and away you go.
The lack of standards in ARM necessitates these board files. One system may boot using one board file, but the next may not be able to get their RAM configured appropriately using the same board file.
And with regards to a consistent ISA, that's not even true. There are multiple implementations of some functionality such as floating point. ARM has a couple implementations (notably Vector Floating Point (VFP) and NEON), but some manufacturers have decided to create their own implementations such as Cirrus' Maverick Crunch. But this isn't even a real concern here, as that is more a matter for the compiler.
Uh, he does kinda say that the goal is to design a tablet interface.
derStandard.at: Are you going to write totally new apps for that or reuse existing ones?
McCann: Whether or not they are new code - that's up for the developers to decide. We really don't want to specify anything about the implementation and let the people who do it choose. But at least for a handful of things we want to design something that's specifically for GNOME3. That's consistent with the rest of the interface, uses all of the right interactions, uses the application menu properly, is designed for a laptop or a tablet. So we want to lead by example.
Slashdot Mirror
I think Belial6 is talking out of his ass. However, there was a time when games would be delivered in a couple of versions, a DOS version and the Windows (95) version. The DOS version usually outperformed the Windows version, but often for technical reasons that didn't actually involve Windows at all. An example would be Descent II. The Windows version performed just fine when fullscreened, but if you ran it windowed there was a performance impact. It isn't all that surprising, considering Windows was emulating a DOS console.
Corporations are people. Large corporations are rich.
Not necessarily. They may be bankrupt.
They're Temporarily Embarrassed Millionaires. Just like the rest of us.
And to "safely" emit EMP, one does it from a very high altitude.
"I say we take off and nuke the site from orbit. It's the only way to be sure."
Although, as Hatta pointed out, slashcode ate his less than symbol, you're still incorrect. "skein [args] FILE" would only make argv[argc-1]="FILE" not the zeroth file descriptor (stdin) equal to "FILE", which is necessary if "echo FILE | skein [args]" and "skein [args] FILE" are to agree. If such a program was made to hash the last argument you'd have to go through a heck of a lot of work escaping your file contents and trying to avoid the maximum argument length.
It is possible that elsurexiste is a very, very large man.
The Linux kernel is GPL2. Unless you're talking about some other Linux, you're incorrect.
Linux is "more complete" than Gnu is.
You're not even wrong.
So what you're saying is that YOU were unaware of the industry-specific oft used phrase "cattle call" and the other phrases, equally demeaning, are okay because some pop culture icons have used them publicly.
I sure hope so! He's only 54, after all.
http://en.wikipedia.org/wiki/Mike_Godwin
Likely still in the USA.
http://en.wikipedia.org/wiki/Mike_Godwin
This can probably be done better than the standard textbooks
. I am fully aware that textbooks push an agenda.
When virtual reality is possible, the student can learn history by "being there".
They can learn what an artist's version of history is. This can probably be done better than the standard textbooks, but it also makes rewriting history easier and more real than the truth written in some book.
He was referring to PLCs not PICs. A level below even the microcontrollers.
Your Scheme-in-one-defun, did is support a standard such as R5RS or R6RS? If not, then you're not making a fair comparison between it and Guile. There are valid reasons for that extra code, not just because the FSF adds needless code to every project.
Although correct, that depends on an exploit to some programming error such as an unchecked buffer access. Programs (and therefore parsers) can be written in such a way that lends itself to automated correctness checking. But, when you permit executable objects to be embedded within your data format, there simply is no way to prove correctness. There are some strategies to limit system exposure to these embedded objects, but as we have seen before, they often leak information or have security vulnerabilities.
TFA does a fine job of demonstrating how passing control to an embedded executable object (Flash) leads to a situation where Microsoft Word, which normally provides warning, fails to inform the user of the potential threat.
Without the dumb effects that made that game so dark (hard to view), the Voodoo 2 makes game looks a lot more fun! Reminds me a bit of the original HalfLife.
Windows has been able to restart the driver successfully
Consider yourself lucky. When playing SC2 under Windows I get a complete lockup once every 3 or 4 days.
Could you explain your reasoning more? I'm not seeing how parsing an ASCII text file or similar static document necessarily means there's a hole to be exploited. Besides, there are numerous documents that are purely descriptive in nature without depending on render time execution.
Cite your sources, because there are numerous studies that refute your claims.
http://www.motorists.org/red-light-cameras/effect-yellow-timing
http://www.motorists.org/red-light-cameras/timing-myths
http://bancams.com/get-the-facts/studies/seattle-yellow-light-times-study/
http://www.shortyellowlights.com/rlcinfo/
Also, quit spouting your "feelings" on the issue when it doesn't match up with facts.
"Anti-intellectualism has been a constant thread winding its way through our political and cultural life, nurtured by the false notion that democracy means that 'my ignorance is just as good as your knowledge.'"
-- Isaac Asimov
This is why they had to wait for shipped rad-hardened robots.
Is there any evidence that the robots their using, iRobot PackBots, are radiation hardened? I am yet to see any. It seems to me that they were simply unprepared for the situation.
[citation needed]
As I have heard just the opposite, that after a few writes the original information drops below the noise floor.
Correct, like those liberal Arabs and their desire to have democracy.
but eventually we need to start working on tools to deal with the complexity.
Like standards?
Sure, but for this you'll have to pardon me as we dig deep. Let's look at the arm branch within the kernel:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=tree;f=arch/arm;h=d247ffd8707069e63d0b065f5be9ce460e062536;hb=HEAD
See each of those mach-* and plat-* directories? Each of those are major architectural variants which use the ARM Instruction Set Architecture for their CPU.
For comparison, here's the X86 arch:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=tree;f=arch/x86;h=b12a856aa5e889280247287d48241beb16eb423c;hb=HEAD
But, to see where the problem really lies let's dig deeper. Let's select a popular architecture, the Texas Instruments OMAP2, also shared by the OMAP3 and OMAP4 series.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=tree;f=arch/arm;h=d247ffd8707069e63d0b065f5be9ce460e062536;hb=HEAD
See all of those board-* files? Each of those represents a specific implementation of the OMAP2+ architecture. The rest of the files are support for the underlying functionality exposed by these board files.
You see, this is a mess. The current state is akin to having each variant of X86 with its own file. E.g. an architecture directory for each PC manufacturer (IBM, Dell, HP, Compaq, Lenovo, etc) and then in each directory the variant implementation files (Lenovo X40, X41, T40, T60, T60p; Compaq Presario CQ50, CQ56, CQ62 and so on). Whenever you change an underlying subsystem used by many boards, such as USB or Flash, you have to visit each of these architectures and boards and update them.
The reason for the mess in ARM is that ARM is the CPU core, an ISA, that's all. Beyond that it is completely nonstandard. Memory locations, flash interfaces, Serial Peripheral Interface (SPI), Two-Wire Interfaces (I2C), USB controllers and numerous other hardware configurations are all chip specific. The PC has standardized these using the BIOS, EFI, PCI and other industry wide standards. Sure you'll need drivers to use the devices, but at least you can boot up and detect them. From there it is simply a matter of loading the module and away you go.
The lack of standards in ARM necessitates these board files. One system may boot using one board file, but the next may not be able to get their RAM configured appropriately using the same board file.
And with regards to a consistent ISA, that's not even true. There are multiple implementations of some functionality such as floating point. ARM has a couple implementations (notably Vector Floating Point (VFP) and NEON), but some manufacturers have decided to create their own implementations such as Cirrus' Maverick Crunch. But this isn't even a real concern here, as that is more a matter for the compiler.
derStandard.at: Are you going to write totally new apps for that or reuse existing ones?
McCann: Whether or not they are new code - that's up for the developers to decide. We really don't want to specify anything about the implementation and let the people who do it choose. But at least for a handful of things we want to design something that's specifically for GNOME3. That's consistent with the rest of the interface, uses all of the right interactions, uses the application menu properly, is designed for a laptop or a tablet. So we want to lead by example.
Emphasis mine.