That is true, and I certainly enjoy video game orchestral type music quite a bit more than "typical" classical music - as you say, it tends to evoke feelings more often. I also find that there are many orchestral video game tunes that nonetheless sound very different from classical music - these composers do things that classical composers don't, even when using the same instruments.
I still wonder what people conditioned into hating classical music would think of these kinds of video game tunes though. I wonder if it's a hate of "common" classical pieces (by name or by sound) or a general dislike for any arrangement that uses classical style instrumentation.
There's a reason why I qualified "How do I do XYZ" with "for a project" (implying a higher goal that is nonetheless unstated) and "where XYZ is one or more of complicated, ridiculous, vague, nonsensical", such that answering is difficult and/or would prove useless most of the time. This isn't a case of a straightforward question being left unanswered; there is a genuine need to know more about the project in order to provide a reasonable and useful answer.
There is such a thing as a generic solution to a problem.
There is no generic solution to this problem (or, equivalently, there are many useless ones). The problem is so open-ended and poorly defined that there are dozens of solutions that strictly speaking meet the requirements, yet the chances of them actually working for his project are slim. If you think you can provide a solution, you're making many assumptions about the project.
I bet you're someone who writes an expert system instead of actually solving the task you set out to do.
He didn't even ask for a solution, he asked for a way to accomplish a poorly specified abstract task that is nontrivial. It's pot luck whether a solution will be valid, and chances are it won't, unless he explains the actual project. For example, if he's trying to test modern disk error correction by introducing errors, suggestions such as "use an old 20MB drive" are useless; on the other hand, if he is just experimenting with magnetism on a drive (e.g. even trying to write "analog" audio data onto a platter) then making his own drive controller for a modern drive is both ridiculously complicated and probably worse than just feeding audio data to an old stepper drive's heads.
Flash chips also contain internal logic to map out defective blocks, and in addition they remap in order to avoid writing single blocks too often in order to prevent them from failing early.
Flash controllers do that, not flash chips (well, some very smart flash chips have a built-in controller, but they aren't exactly common). It's very easy to buy a raw NOR or NAND flash chip and control every bit (with NOR you don't even need bad block management, as all blocks are guaranteed valid within the specified number of writes).
NOR flash doesn't require or use wear leveling, error correction, or bad sector management (as long as your wear pattern isn't ridiculously unbalanced) - use that if you want true "write raw bits" style functionality. Most microcontrollers use this type of flash, and chips are readily available, though they are expensive compared to NAND flash and only exist in smaller sizes.
NAND flash requires you do your own wear leveling, error correction, and bad sector management. You can still control all the bits, but be prepared to have the chip eat some of them.
Only "cooked" NAND flash devices such as SSDs and SD cards actually do all that on a built-in controller.
The stuff Spinrite does stopped working 15 years ago. On modern drives you're pretty much doomed. Considering Gibson has been known to rip off SYN cookies and spout such nonsense as "Windows RAW sockets are going to destroy the internet", I wouldn't go anywhere near him for advice.
These kinds of questions are stupid: "I need to do XYZ for a project, how do I do XYZ?", where XYZ is one or more of complicated, ridiculous, vague, nonsensical, etc. Try telling us what your project is, and then we might be able to suggest a useful solution, possibly not involving XYZ at all, or involving a very particular/practical version of XYZ.
Just found out that "the number" is one: FeaturePak features (no pun...) two PCI-Express lanes and two USB buses (and hosts only have to implement one of each anyway). Color me unimpressed.
It's not even a new connector. They use the MXM connector used for laptop video cards. Looks like they just replaced all of the video I/O pins with an incompatible free-for-all and made the card somewhat shorter.
MXM is the connector used for modern laptop video cards (essentially PCIe x16 + video/monitor out)
Let's see: FeaturePak uses the same connector, FeaturePak uses PCIe, FeaturePak has a bunch of undefined IO pins. Sounds to me like MXM, except they replace the video-card-specific but mostly standardized video out signals with totally unspecified "put whatever you want here, including power" signals. Great.
This doesn't look like it's aimed at laptops at all (unlike Mini PCI Express, which is the form factor used for small PCIe modules such as video capture cards and WiFi). This sounds like it's more suited to small form factor embedded platforms for industrial/medical/etc use.
Microsoft did not attach random numbers to each entry in the list. That does work. What Microsoft did is return random results for a compare function. There's a big difference there, because in the former case the compare function will return consistent, coherent results for a randomized list, while in the latter case the compare function will return random, inconsistent, meaningless results. You might see some similarity there (use of a sorting function), but the algorithms are completely different, and only Microsoft's is horribly broken.
All I'm trying to say is that the.txt file that you cited is talking about academically ideal randomness and stuff that doesn't really apply here, because, although sorting a list by some form of binary random numbers will always have a tiny roundoff bias (lower the bigger the number you use), that kind of minimal bias is completely irrelevant in pretty much all real world uses. Microsoft's problem is different, and although their method is related, the problem that they have has nothing to do with what the.txt file explains.
Attaching random numbers to each list item and sorting does work for all practical purposes, as long as you use a reasonably large set of possible random numbers (e.g. a 32-bit float, not a one-bit integer as your worst-case example mentions). What Microsoft did is far worse: abuse a black box sort function by violating the specification for the compare function, and somehow assume that this black box will spit out random results. The former will never be truly mathematically optimal (which is the point of the article you cite), but it will be plenty good enough (probably indistinguishably so from a perfect one) in 99% of non-deliberately-broken implementations (to the point where you start caring about Math.Random itself). The latter is pretty much guaranteed to fail catastrophically, as we see here.
It's worth noting that neither picking a random permutation nor performing a bunch of random swap operations are likely to be mathematically ideal unless you have a random number generator capable of producing perfectly uniform random numbers within an arbitrary range (and this is basically the same kind of issue that you get when attaching numbers and sorting). Long story short, unless your total randomness utilized is essentially represented as a number that's a multiple of the number of permutations of what you're shuffling, you're going to get some (usually extremely minor) roundoff biases.
USB-Serial (using decent chips) works great for actual serial port use. The stuff that doesn't work tends to be that which depends on precise serial timing to work (ew) uses the control pins to transfer data or bitbang (eew). I've never seen a proper USB to serial adapter fail when used to talk to an actual serial device (crappy chinese adapters need not apply - those can be horrid).
They poured a tonne of work into making this happen. Just because they control the hardware their hard work isn't worth anything? I think it's pretty cool what they've been able to do, someone no one else in the history of Linux has ever been able to do.
I'm not sure this is a first, nor am I sure this took that much work. Using DMA to optimize the obvious three or four huge RAM copies during boot is hardly a tonne of work. That's more like a week of work.
Look up the twin paradox. Not that I'm a physicist, but so far everything I've read indicates that this form of time travel is, in fact, possible in a theoretical sense; i.e. if one twin leaves on a spaceship at relativistic speeds and then comes back, he will actually have aged less than the twin not undergoing acceleration/deceleration.
Yup, 1-second embedded boot is fairly is fairly nice but the summary is misleading and this is not even remotely comparable to desktop boot times. They're using an initramfs, no real filesystem, and no real distribution.
To put things into perspective, I have an OMAP3530 platform in front of me (same as TFA, funny coincidence) and a totally vanilla kernel that I compiled a few days ago boots in 2.5 seconds, not counting the long time wasted by the totally suboptimal bootloader (3-second deliberate boot delay, networking support, loading the kernel from an SD card, all that crap). That time includes mounting an ext3 filesystem from an SD card and starting to run init from it, and the kernel has built-in drivers for all onboard hardware including USB host+OTG, Ethernet, networking (ipv4 and ipv6), HDMI display output, audio, etc. Of course, booting the rest of the (real, full-blown) distro up takes a while as usual, but TFA is basically showing an embedded application that could be as simple as a single binary running from initramfs (I've actually poked a MontaVista Linux system once, and their startup was basically a single shell script - not quite SysV Init!). Remove the sd/ext3 stuff, remove useless drivers, replace the bootloader with a minimal build, use a busybox shell script + a single executable binary for the actual application, and you're probably getting close to 2-second total boot times without even beginning to optimize stuff with DMA and the like.
Exactly, if by "time travel" you mean go on a spaceship, accelerate to near-light speeds, and then come back later. You'll still age at the same rate yourself, it's just that a (potentially much) longer time will have passed for others by the time you make it back. So you could "time travel" forward a century in the real world in one year from your point of view, but you're still only one year older.
One way to put it is that, once you take relativity into account, calculating your age by subtracting your birth date from the current date no longer works (if you're going by international atomic time or some other Earth-based standard), because the ways we commonly measure and compare time assume it is absolute, while it actually is relative. What would work would be simply carrying a watch around yourself.
It's worth noting that relativity has been tested and works, and in fact many of us rely on it every day: GPS satellite clocks run slower internally in order to account for relativity (from Earth, we perceive them to run at the correct speed, but if you were standing on the satellite, you'd see it run a very tiny bit slower - about 0.4 parts per billion).
There are separate correction factors for special relativity (what we're talking about here - time dilation due to travel) and general relativity (which is different and has to do with the gravitational field - i.e. the satellites are farther away from Earth than the receivers). GPS combines both, so we know both theories "work" in this situation. GPS requires extremely accurate clocks, and without this compensation your GPS position would actually drift off 10km per day.
You're thinking of time dilation as being related to your "brain clock" or the way your brain recognizes time. It isn't. Time itself is relative, and it works at a level below body chemistry. If you're traveling at near light speed, time will appear to pass normally to you (and to your cells, and to a digital clock that you're carrying, and to anything else with you), but in fact external observers will appear to age faster. To them, you're aging slowly and they're aging normally.
The key word is time. The progression of time itself changes, not the time it takes for biological processes to happen. One second is still one second, and the same things happen to you in one second as they would otherwise, it's just that your second isn't equal to the outside world's second.
No, that's totally wrong. The drive may well use 10 magnetic "cells" to store a byte (e.g. with 8b10b modulation or something similar), but that's an implementation detail. As far as everything else is concerned, bytes are 8 bits.
If Advanced Format drives were true 4k drives (i.e. they didn't lie to the OS and claim they were 512 byte drives), they'd work great on Linux (and not at all on XP). Since they lie, Linux tools will have to be updated to assume the drive lies and default to 4k alignment. Anyway, you can already use manual/advanced settings in most Linux parititioning tools to manually work around the issue.
Slashdot Mirror
That is true, and I certainly enjoy video game orchestral type music quite a bit more than "typical" classical music - as you say, it tends to evoke feelings more often. I also find that there are many orchestral video game tunes that nonetheless sound very different from classical music - these composers do things that classical composers don't, even when using the same instruments.
I still wonder what people conditioned into hating classical music would think of these kinds of video game tunes though. I wonder if it's a hate of "common" classical pieces (by name or by sound) or a general dislike for any arrangement that uses classical style instrumentation.
I wonder what they'll think of Video Games Live. Will "repugnant" classical music + awesome video game tunes make their heads explode?
There's a reason why I qualified "How do I do XYZ" with "for a project" (implying a higher goal that is nonetheless unstated) and "where XYZ is one or more of complicated, ridiculous, vague, nonsensical", such that answering is difficult and/or would prove useless most of the time. This isn't a case of a straightforward question being left unanswered; there is a genuine need to know more about the project in order to provide a reasonable and useful answer.
There is no generic solution to this problem (or, equivalently, there are many useless ones). The problem is so open-ended and poorly defined that there are dozens of solutions that strictly speaking meet the requirements, yet the chances of them actually working for his project are slim. If you think you can provide a solution, you're making many assumptions about the project.
I bet you're someone who writes an expert system instead of actually solving the task you set out to do.
He didn't even ask for a solution, he asked for a way to accomplish a poorly specified abstract task that is nontrivial. It's pot luck whether a solution will be valid, and chances are it won't, unless he explains the actual project. For example, if he's trying to test modern disk error correction by introducing errors, suggestions such as "use an old 20MB drive" are useless; on the other hand, if he is just experimenting with magnetism on a drive (e.g. even trying to write "analog" audio data onto a platter) then making his own drive controller for a modern drive is both ridiculously complicated and probably worse than just feeding audio data to an old stepper drive's heads.
Flash controllers do that, not flash chips (well, some very smart flash chips have a built-in controller, but they aren't exactly common). It's very easy to buy a raw NOR or NAND flash chip and control every bit (with NOR you don't even need bad block management, as all blocks are guaranteed valid within the specified number of writes).
NOR flash doesn't require or use wear leveling, error correction, or bad sector management (as long as your wear pattern isn't ridiculously unbalanced) - use that if you want true "write raw bits" style functionality. Most microcontrollers use this type of flash, and chips are readily available, though they are expensive compared to NAND flash and only exist in smaller sizes.
NAND flash requires you do your own wear leveling, error correction, and bad sector management. You can still control all the bits, but be prepared to have the chip eat some of them.
Only "cooked" NAND flash devices such as SSDs and SD cards actually do all that on a built-in controller.
The stuff Spinrite does stopped working 15 years ago. On modern drives you're pretty much doomed. Considering Gibson has been known to rip off SYN cookies and spout such nonsense as "Windows RAW sockets are going to destroy the internet", I wouldn't go anywhere near him for advice.
These kinds of questions are stupid: "I need to do XYZ for a project, how do I do XYZ?", where XYZ is one or more of complicated, ridiculous, vague, nonsensical, etc. Try telling us what your project is, and then we might be able to suggest a useful solution, possibly not involving XYZ at all, or involving a very particular/practical version of XYZ.
Just found out that "the number" is one: FeaturePak features (no pun...) two PCI-Express lanes and two USB buses (and hosts only have to implement one of each anyway). Color me unimpressed.
It's not even a new connector. They use the MXM connector used for laptop video cards. Looks like they just replaced all of the video I/O pins with an incompatible free-for-all and made the card somewhat shorter.
MXM is the connector used for modern laptop video cards (essentially PCIe x16 + video/monitor out)
Let's see: FeaturePak uses the same connector, FeaturePak uses PCIe, FeaturePak has a bunch of undefined IO pins. Sounds to me like MXM, except they replace the video-card-specific but mostly standardized video out signals with totally unspecified "put whatever you want here, including power" signals. Great.
This doesn't look like it's aimed at laptops at all (unlike Mini PCI Express, which is the form factor used for small PCIe modules such as video capture cards and WiFi). This sounds like it's more suited to small form factor embedded platforms for industrial/medical/etc use.
Microsoft did not attach random numbers to each entry in the list. That does work. What Microsoft did is return random results for a compare function. There's a big difference there, because in the former case the compare function will return consistent, coherent results for a randomized list, while in the latter case the compare function will return random, inconsistent, meaningless results. You might see some similarity there (use of a sorting function), but the algorithms are completely different, and only Microsoft's is horribly broken.
All I'm trying to say is that the .txt file that you cited is talking about academically ideal randomness and stuff that doesn't really apply here, because, although sorting a list by some form of binary random numbers will always have a tiny roundoff bias (lower the bigger the number you use), that kind of minimal bias is completely irrelevant in pretty much all real world uses. Microsoft's problem is different, and although their method is related, the problem that they have has nothing to do with what the .txt file explains.
Attaching random numbers to each list item and sorting does work for all practical purposes, as long as you use a reasonably large set of possible random numbers (e.g. a 32-bit float, not a one-bit integer as your worst-case example mentions). What Microsoft did is far worse: abuse a black box sort function by violating the specification for the compare function, and somehow assume that this black box will spit out random results. The former will never be truly mathematically optimal (which is the point of the article you cite), but it will be plenty good enough (probably indistinguishably so from a perfect one) in 99% of non-deliberately-broken implementations (to the point where you start caring about Math.Random itself). The latter is pretty much guaranteed to fail catastrophically, as we see here.
It's worth noting that neither picking a random permutation nor performing a bunch of random swap operations are likely to be mathematically ideal unless you have a random number generator capable of producing perfectly uniform random numbers within an arbitrary range (and this is basically the same kind of issue that you get when attaching numbers and sorting). Long story short, unless your total randomness utilized is essentially represented as a number that's a multiple of the number of permutations of what you're shuffling, you're going to get some (usually extremely minor) roundoff biases.
USB-Serial (using decent chips) works great for actual serial port use. The stuff that doesn't work tends to be that which depends on precise serial timing to work (ew) uses the control pins to transfer data or bitbang (eew). I've never seen a proper USB to serial adapter fail when used to talk to an actual serial device (crappy chinese adapters need not apply - those can be horrid).
I'm not sure this is a first, nor am I sure this took that much work. Using DMA to optimize the obvious three or four huge RAM copies during boot is hardly a tonne of work. That's more like a week of work.
No, but it does run Quake 3 at a very playable framerate (these things have a 3D accelerator in them) ;)
Look up the twin paradox. Not that I'm a physicist, but so far everything I've read indicates that this form of time travel is, in fact, possible in a theoretical sense; i.e. if one twin leaves on a spaceship at relativistic speeds and then comes back, he will actually have aged less than the twin not undergoing acceleration/deceleration.
No, of 1.5 seconds. The 1-second mark is a guesstimate based on subtracting power sequencing time from the actual 1.5-second mark, approximately.
Yup, 1-second embedded boot is fairly is fairly nice but the summary is misleading and this is not even remotely comparable to desktop boot times. They're using an initramfs, no real filesystem, and no real distribution.
To put things into perspective, I have an OMAP3530 platform in front of me (same as TFA, funny coincidence) and a totally vanilla kernel that I compiled a few days ago boots in 2.5 seconds, not counting the long time wasted by the totally suboptimal bootloader (3-second deliberate boot delay, networking support, loading the kernel from an SD card, all that crap). That time includes mounting an ext3 filesystem from an SD card and starting to run init from it, and the kernel has built-in drivers for all onboard hardware including USB host+OTG, Ethernet, networking (ipv4 and ipv6), HDMI display output, audio, etc. Of course, booting the rest of the (real, full-blown) distro up takes a while as usual, but TFA is basically showing an embedded application that could be as simple as a single binary running from initramfs (I've actually poked a MontaVista Linux system once, and their startup was basically a single shell script - not quite SysV Init!). Remove the sd/ext3 stuff, remove useless drivers, replace the bootloader with a minimal build, use a busybox shell script + a single executable binary for the actual application, and you're probably getting close to 2-second total boot times without even beginning to optimize stuff with DMA and the like.
Exactly, if by "time travel" you mean go on a spaceship, accelerate to near-light speeds, and then come back later. You'll still age at the same rate yourself, it's just that a (potentially much) longer time will have passed for others by the time you make it back. So you could "time travel" forward a century in the real world in one year from your point of view, but you're still only one year older.
One way to put it is that, once you take relativity into account, calculating your age by subtracting your birth date from the current date no longer works (if you're going by international atomic time or some other Earth-based standard), because the ways we commonly measure and compare time assume it is absolute, while it actually is relative. What would work would be simply carrying a watch around yourself.
It's worth noting that relativity has been tested and works, and in fact many of us rely on it every day: GPS satellite clocks run slower internally in order to account for relativity (from Earth, we perceive them to run at the correct speed, but if you were standing on the satellite, you'd see it run a very tiny bit slower - about 0.4 parts per billion).
There are separate correction factors for special relativity (what we're talking about here - time dilation due to travel) and general relativity (which is different and has to do with the gravitational field - i.e. the satellites are farther away from Earth than the receivers). GPS combines both, so we know both theories "work" in this situation. GPS requires extremely accurate clocks, and without this compensation your GPS position would actually drift off 10km per day.
Whoops. Yeah, I was thinking of the "twin paradox" situation where you accelerate out and then come back.
You're thinking of time dilation as being related to your "brain clock" or the way your brain recognizes time. It isn't. Time itself is relative, and it works at a level below body chemistry. If you're traveling at near light speed, time will appear to pass normally to you (and to your cells, and to a digital clock that you're carrying, and to anything else with you), but in fact external observers will appear to age faster. To them, you're aging slowly and they're aging normally.
The key word is time. The progression of time itself changes, not the time it takes for biological processes to happen. One second is still one second, and the same things happen to you in one second as they would otherwise, it's just that your second isn't equal to the outside world's second.
No, that's totally wrong. The drive may well use 10 magnetic "cells" to store a byte (e.g. with 8b10b modulation or something similar), but that's an implementation detail. As far as everything else is concerned, bytes are 8 bits.
If Advanced Format drives were true 4k drives (i.e. they didn't lie to the OS and claim they were 512 byte drives), they'd work great on Linux (and not at all on XP). Since they lie, Linux tools will have to be updated to assume the drive lies and default to 4k alignment. Anyway, you can already use manual/advanced settings in most Linux parititioning tools to manually work around the issue.