Your questions about musical technicalities aside, since I know little about music theory (though I'd assume specifically using B# instead of C reflects the different role of the note in whatever piece of music the previous poster was thinking off), you miss the point entirely. This is not about "associating imagery with music".
When most people "associate imagery" with music, that is exactly what we do - we connect some image that seems suitable, with the music, coloured by our experiences, what we know about the music etc.
When someone with synesthesia see a colour when they hear a note, that is exactly what it means, and that colour is tied to that specific note irrespective of experience, memory etc.
The images I associate with a piece of music change all the time depending on whether I perhaps learn something else about the music, or have an experience related to the music or thousands of other reasons.
The colours someone who "sees music" as a result of synesthesia experience normally stays the same throughout life, and are equivalent of the experience of seeing, not of association or "picturing" something.
The big problem with just "sticking the stuff into a suitable part of the brain" (besides the question of whether or not the brain would figure it out) is that you're massively increasing the risk of dangerous infections.
Not to mention that hardly any distribution uses unmodified kernels from Linus, and that half a dozen (or more) people maintain separate kernel trees that often end up carrying specific features for ages without getting them into the mainline kernel.
The Linux kernel is extremely fragmented, and the only reason Linus' kernel remain relevant is because he's shown himself to be pragmatic enough about what he'll include that people find it worthwhile trying to sync with him where possible.
How it could be more Bazaar like is beyond me - various strains survive purely based on merit, and features appear or disappear based on what gets popular or what doesn't get any traction. At any point there can be a total chaos of available versions solving any number of different problems.
Linus just happens to keep being that guy that built a name by being the original author, and keep his reputation by getting his version good enough for enough people to keep the "customers" coming. If he starts screwing up, someone else will take all his "business" and he'll end up being ignored. At the same time there keeps being enough niches for tons of other versions, because not everyone has the same goals.
Contrast that to Java, where no matter what happens, Sun is the final arbiter.
Unless Santa Cruz' bus system has improved in the last couple of years, it's a complete and utter joke. But then that's from the perspective of a Norwegian who's now living in London. No matter how much the Brit's like to moan about public transport, going to the US without having access to a car (I'm 29, but have never bothered getting a drivers license, which I guess does say a bit about the quality of public transport where I've lived) is one of the most annoying experiences ever.
I don't doubt that Santa Cruz's bus system may be "pretty good" by US standards, but that doesn't say much.
If I'd been living in the US I'd probably be using a car too, unless I happened to live in one of the few major cities that have decent public transportation.
Not all trains have human drivers. The Docklands Light Railway in London is driver less (though there is a human on board that can take over, that person is normally occupied with other tasks).
Remember in any case that the computer doesn't need to be flawless to be useful, as long as it's safer than most human drivers. Also, there's a huge sliding scale from an entirely human operated car to an entirely computer driven one.
For the foreseeable future, a more likely approach is more computer assistance, like enforcing speed limits, emergency intervention (like breaking if there is something too close in front, or stopping/reducing dangerous human reflexes like the way many human drivers get spooked into hitting the brakes hard when their grip is slipping on icy roads), automatic course correction in certain circumstances (like if you're weering over into a different lane and the car doesn't detect any attempts at correcting the course manually).
Attacking the problem piece by piece is much more likely to be accepted and useful than waiting until you can replace a driver completely. It's also much easier to make safe since you can focus on testing the small changes incrementally much more thoroughly.
Because they're all targetted to HIS e-mail patterns, which surely includes being signed up to thousands of mailing lists, having his address regularly entered on websites by people who don't want to give out their own address, etc.
Your counter arguments just doesn't wash. The point is NOT that any of the purchases would be sufficient proof of something, but that they may put you in a bucket together with people more likely to do something, and so might be treated differently DESPITE there not being sufficient evidence. If there's sufficient evidence without data about your purchases, then nobody would particularly care - it's not as if it'll matter to anyone whether or not you bought a knife an hour before a murder if you were seen comitting the murder and found with the knife in your hand.
Yes, you'd need a physical for many health insurance schemes, but how often? And how detailed? It's quite possible that bad eating habits could put you in a category of people with increased risk of certain problems long before the problems would show up on a physical if the data are regularly analyzed.
And yes, it does make sense for an insurance company to drop you, or increase the cost of your insurance, or take whatever action is legal where you live, to get rid of you if they can see a correlation between their customers alcohol purchases and accident statistics that is sufficient that they're likely to lose money on you- it's not like all drunk drivers crash or get stopped by the cops the first time they've been driving drunk. You might be a careful driver that don't tend to drink a lot, but still are sufficiently of an increased risk due to drinking that you're not likely to be a profitable customer.
And as for the court example. Yes it would be purely circumstantial. However that does not mean it won't influence peoples decisions to the point where it could tip the scales if you were unlucky. Your arguments against it are arguments against the specific example, not the general issue: records that are purely circumstantial can be abused to try to tighten up an otherwise bad case.
Compare it to the way it has (and still is many places) common for the defense in rape cases to try to bring the way the victim dresses and acts into the case to influence judge and jury.
Consider that an example instead then, since that is a very real problem. What if a rape victim gets confronted with purchase records showing she bought sex underwear the day before the rape? It's not in any way "evidence" of consent - take the number of rapes and the number of people who buy sexy underwear every day, and there's bound to be quite likely that some rape victims have indeed bought sexy underwear shortly before their rape.
However this is exactly the kind of "evidence" that frequently HAS been used to get people off the hook in rape cases.
You're side stepping the issue, which is that any easily processed data about you increases the opportunities for abuse. A video tape from a store could be used, but that would require someone to know that you purchased something in a specific store AND consider it important enough to spend a lot of time looking through the tapes AND positively ID you AND manage to pick out what you were purchasing based on grainy security tapes.
Compare that to using a system to automatically scan through purchase records looking for "interesting" items based on type of data wanted (the police might want records of alcohol purchases, or piano wire purchases, or knife purchases, your insurers might want records of alcohol, sleeping tablets and other drugs that might leave you unfit to drive, or any drugs that doesn't match the info you have given them perfectly).
If the data is easily enough available, some of the info may even trigger preemptive warnings. Buying a large knife late at night? Let's dispatch police to your home just in case.
Now, none of these scenarios may ever come to pass, and most people might agree that none of this data should ever be used this way, but if so then there should be no reason not to take precautions to make sure it can't happen, or to make it significantly harder for it to happen. Measures to protect privacy (and similarly measures to safeguard democrac
Because it's not easy to determine if the new registrar has any rights to request the transfer in the first place. For instance, the new registrar might not actually represent the person who bought the domain, or the current registrar might have a contract with the owner that restricts the owners actions (for instance denying transfers until accounts have been settled in full), or there might be a court order in place restricting what can be done by the domain etc. Letting registrars unilaterally transfer domains would be a big problem, because past experience indicates that some registrars WOULD abuse it to take control over customers they have no relation to.
Authentication mechanisms in EPP is starting to make it easier, but that still only works if your current registrar will actually give you the auth info you need.
Duh. This is about approval of transfers, not expiration. Transfer requests can happen at any time.
Re:How is this not totally pointless?
on
The Real da Vinci Code
·
· Score: 3, Insightful
How do you know it didn't inspire anyone to copy him? The article describes a text from 1600 about an automaton that was deviced along "similar principles" as one that DaVinci had presented in 1515, so apparently his work on this was known at the time, even though not much appears to have been preserved. Who knows how many of the people who played a great role in the huge number of automatons that were built were inspired directly by DaVinci, or indirectly by automatons built by people inspired by DaVinci? Who knows how much of this work carried over into other work on automation, and ultimately over into computing?
The thing is, one of the key mysteries around DaVinci is that very little is known about how many of his ideas were led to working machines, and how many that were publicly known in his own time. Hence very little is known about the degree to which he influenced or didn't influence development.
The industrialized world have had vast over production of food for decades, and that has done nothing to prevent starvation in the developing countries, so why do you think using corn this way will change that? If anything, if it raises the price of corn it may increase corn prices and increase the income for some of these countries, allowing them to spend more resources on purchasing cheap food sources to cover shortfalls in their own food production.
Also, less than 50% of corn harvests is already used for human consumption. Most of the rest go to animal food and fuel production.
Starvation is a distribution problem, not a production problem.
The world produces more than enough food, but there isn't political will to 1) ensure efficient crisis management and delivery and 2) provide development assistance sufficient to ensure production capabilities where needs are greatest. And then there are genocidal maniacs like Mugabe that ruins his countrys capability to stay self sufficient and uses the threat of starvation to control his opposition.
Because that was for async bus operation, not async internal operation. The 68000 is fully synchroneous internally, as most/all other commercially successfull CPU's. Async buses is nothing new, and the ability to support it on the 68000 was in fact mostly to allow it to integrate with older hardware.
But for any of this to have ANY value, the people in question needs to have seriously considered all the available data and acurately predicted the outcome.
The number of people who regularly lose money on stock markets, and even more so the number of people who gamble with no basis in fact should indicate that it's unlikely to be a great indicator. Even more if the people involved are self selected, in which case the chance is high that the numbers are influenced by a number of people who are unreasonably sure about their choice because of personal convictions.
While many VC's did catastrophic investments, most of them are VERY good at protecting their investments from ending in the founders pockets until they've sold out, or the company has gone public. I'm sure a portion of dot-com founders that burned their VC's badly still managed to get out with lots of cash, particularly for companies that survived until some time after an IPO, but the majority likely were stuck with peanuts.
It's because of an attitude like that about 90% of businesses fold within 2-3 years of being started.
Proper strategic planning can be learnt. Project management can be learnt. Business analysis can be learnt. Basics like learning methods for cost benefits analysis (i.e. not selling at a loss isn't always easy to avoid if the product or service is complex unless you actually spend some time figuring out how much it costs you to provide it), risk analysis, good hiring practices, basic accounting (good for staying out of jail...).
Most of "entrepeneurship" is just about having some skills in a wide variety of areas, and knowing how to look for oppotunities, though ome people make do with just being great at adapting.
I've worked in several startups, and co-founded three of them - the first time we made so many stupid mistakes you wouldn't believe it that could have trivially been avoided if any of us had learned a few of the skills mentioned above. In the next two I wasn't involved in the day to day running of the business, and that is perhaps the biggest regret I have for them, as I saw quite a few repeats of mistakes I'd made myself in my first startup. However I also saw the differences brought in by professional hires in areas of the business that actually had experience in some of those fields.
In a way it was a great experience, though painful, in that I've seen first hand what a difference different approaches makes, and I've learned a lot about what it takes to clean up problems that will otherwise eventually kill a business.
A lot of people will succeed in building a business that can feed them, but even more will fail, and vanishingly few will succeed in building a business that will grow large. The odds of success are badly against you to begin with. If you do aquire some of the skills mentioned you're at least improving your chance of being in the 10% or so that survives more than 3 years significantly.
My advice is take your time to prepare properly first. Yes, there are a lot of things you will need to pick up from experience, but you're much more likely to see your business live long enough to gain that experience if you're well prepared and have picked up some essential skills.
My second advice would be: Make sure you know when to quit and wind your business up in a responsible way. It's better to close down and try again later, that keep flogging a dead horse and burning yourself out. That includes even if your business can keep floating, but you are unhappy with returns and you don't see improvements at a reasonable rate (for YOUR definition of reasonable). Get a regular job, and look for the next opportunity when you're ready for it.
Yes, that covers READING the file, but it doesn't cover how exactly the contents of that file are to be divined from the hardware. It also doesn't cover where the object files for compilation are going to life. Even a ram-disk needs a driver.
Sigh. No, it doesn't cover reading the file from the hardware because reading the initrd image is the job of the bootloader. Why don't you try learning a bit about the process before spouting crap?
The compile products (object files) easily blow out to twice that. And the compiler itself consumes a tremendous amount of memory assembling that object files. And then once you have the object files, the linker steps in, which also requires a tremendous amount of memory.
TCC doesn't need a separate linker - it can compile and link in one go straight to RAM. It doesn't need to assemble or output object files.
And no, writing to disk is not a requirement - try actually looking at TCCBOOT before you write about it.
You're right it takes a lot of RAM, but it doesn't really matter - this isn't exactly something most people will ever run for anything but testing. And this RAM requirement will be only until the kernel has been compiled, at which point the initrd image and all the RAM used for the compilation can be freed.
Yes, it's on a filesystem, but if you'd bothered to actually look at the source you would have seen that TCCBOOT includes code to unzip the romfs filesystem and read files from it without any kernel support. And TCC does NOT need to output to a filesystem, it can compile straight to memory and execute the compiled code.
If you seriously think that the approximately 12.000 lines of TCCBOOT code is "most of an OS kernel" you need to have a long look at the core of the Linux kernel some day. Those 12.000 lines contains mostly gunzip, romfs support code, a malloc implementation and a math library.
Of that, less than 500 lines is the filesystem support.
You can do that with TCC, though not automatically. TCC comes with a library you can link with to compile C code and execute it at runtime, so you can use C as an extension language for your app and compile it as and when you need it.
Good point. Imagine getting to the point where you can do kernel development and just start qemu to boot and compile the kernel you're working on on the fly...
Testing kernel changes "almost" on the fly can already be done to some extent by compiling the kernel separately, and then starting an emulator or user mode linux, but this could take it one step further.
Why does TCC require an already running kernel? The only facilities TCC needs is the ability to read source from somewhere, output binary code to somewhere, and allocate memory. All can trivially be supported with a tiny bit of support code. No need for a kernel.
P-code sucks. If you want to do that, you'd be better off generating Java bytecode - at least some real effort have gone into optimizing execution of Java bytecode.
Another option is system like Semantic Dictionary Encoding (M. Franz. Code-Generation On-the-Fly: A Key to Portable Software. PhD thesis, ETH Zurich, Mar. 1994. - It's available online on ETH's servers somewhere but I don't have time to dig it up) - which was (is?) in use by the Mac Oberon people to generate CPU independent binaries.
TCC is an incredibly tiny compiler with practically no dependencies on the environment. It's based on a cleaned up entry to the obfuscated C contest. So you can safely assume it's using every dirty trick in the book and then some. It still sounds incredible though.
Slashdot Mirror
When most people "associate imagery" with music, that is exactly what we do - we connect some image that seems suitable, with the music, coloured by our experiences, what we know about the music etc.
When someone with synesthesia see a colour when they hear a note, that is exactly what it means, and that colour is tied to that specific note irrespective of experience, memory etc.
The images I associate with a piece of music change all the time depending on whether I perhaps learn something else about the music, or have an experience related to the music or thousands of other reasons.
The colours someone who "sees music" as a result of synesthesia experience normally stays the same throughout life, and are equivalent of the experience of seeing, not of association or "picturing" something.
The big problem with just "sticking the stuff into a suitable part of the brain" (besides the question of whether or not the brain would figure it out) is that you're massively increasing the risk of dangerous infections.
The Linux kernel is extremely fragmented, and the only reason Linus' kernel remain relevant is because he's shown himself to be pragmatic enough about what he'll include that people find it worthwhile trying to sync with him where possible.
How it could be more Bazaar like is beyond me - various strains survive purely based on merit, and features appear or disappear based on what gets popular or what doesn't get any traction. At any point there can be a total chaos of available versions solving any number of different problems.
Linus just happens to keep being that guy that built a name by being the original author, and keep his reputation by getting his version good enough for enough people to keep the "customers" coming. If he starts screwing up, someone else will take all his "business" and he'll end up being ignored. At the same time there keeps being enough niches for tons of other versions, because not everyone has the same goals.
Contrast that to Java, where no matter what happens, Sun is the final arbiter.
I don't doubt that Santa Cruz's bus system may be "pretty good" by US standards, but that doesn't say much.
If I'd been living in the US I'd probably be using a car too, unless I happened to live in one of the few major cities that have decent public transportation.
Remember in any case that the computer doesn't need to be flawless to be useful, as long as it's safer than most human drivers. Also, there's a huge sliding scale from an entirely human operated car to an entirely computer driven one.
For the foreseeable future, a more likely approach is more computer assistance, like enforcing speed limits, emergency intervention (like breaking if there is something too close in front, or stopping/reducing dangerous human reflexes like the way many human drivers get spooked into hitting the brakes hard when their grip is slipping on icy roads), automatic course correction in certain circumstances (like if you're weering over into a different lane and the car doesn't detect any attempts at correcting the course manually).
Attacking the problem piece by piece is much more likely to be accepted and useful than waiting until you can replace a driver completely. It's also much easier to make safe since you can focus on testing the small changes incrementally much more thoroughly.
Because they're all targetted to HIS e-mail patterns, which surely includes being signed up to thousands of mailing lists, having his address regularly entered on websites by people who don't want to give out their own address, etc.
Yes, you'd need a physical for many health insurance schemes, but how often? And how detailed? It's quite possible that bad eating habits could put you in a category of people with increased risk of certain problems long before the problems would show up on a physical if the data are regularly analyzed.
And yes, it does make sense for an insurance company to drop you, or increase the cost of your insurance, or take whatever action is legal where you live, to get rid of you if they can see a correlation between their customers alcohol purchases and accident statistics that is sufficient that they're likely to lose money on you- it's not like all drunk drivers crash or get stopped by the cops the first time they've been driving drunk. You might be a careful driver that don't tend to drink a lot, but still are sufficiently of an increased risk due to drinking that you're not likely to be a profitable customer.
And as for the court example. Yes it would be purely circumstantial. However that does not mean it won't influence peoples decisions to the point where it could tip the scales if you were unlucky. Your arguments against it are arguments against the specific example, not the general issue: records that are purely circumstantial can be abused to try to tighten up an otherwise bad case.
Compare it to the way it has (and still is many places) common for the defense in rape cases to try to bring the way the victim dresses and acts into the case to influence judge and jury.
Consider that an example instead then, since that is a very real problem. What if a rape victim gets confronted with purchase records showing she bought sex underwear the day before the rape? It's not in any way "evidence" of consent - take the number of rapes and the number of people who buy sexy underwear every day, and there's bound to be quite likely that some rape victims have indeed bought sexy underwear shortly before their rape.
However this is exactly the kind of "evidence" that frequently HAS been used to get people off the hook in rape cases.
You're side stepping the issue, which is that any easily processed data about you increases the opportunities for abuse. A video tape from a store could be used, but that would require someone to know that you purchased something in a specific store AND consider it important enough to spend a lot of time looking through the tapes AND positively ID you AND manage to pick out what you were purchasing based on grainy security tapes.
Compare that to using a system to automatically scan through purchase records looking for "interesting" items based on type of data wanted (the police might want records of alcohol purchases, or piano wire purchases, or knife purchases, your insurers might want records of alcohol, sleeping tablets and other drugs that might leave you unfit to drive, or any drugs that doesn't match the info you have given them perfectly).
If the data is easily enough available, some of the info may even trigger preemptive warnings. Buying a large knife late at night? Let's dispatch police to your home just in case.
Now, none of these scenarios may ever come to pass, and most people might agree that none of this data should ever be used this way, but if so then there should be no reason not to take precautions to make sure it can't happen, or to make it significantly harder for it to happen. Measures to protect privacy (and similarly measures to safeguard democrac
Not until I know whether or not Bush is capable of finding someone even worse to replace him.
Authentication mechanisms in EPP is starting to make it easier, but that still only works if your current registrar will actually give you the auth info you need.
Duh. This is about approval of transfers, not expiration. Transfer requests can happen at any time.
The thing is, one of the key mysteries around DaVinci is that very little is known about how many of his ideas were led to working machines, and how many that were publicly known in his own time. Hence very little is known about the degree to which he influenced or didn't influence development.
Being biodegradable doesn't mean that it has to degrade quickly under normal usage conditions.
Also, less than 50% of corn harvests is already used for human consumption. Most of the rest go to animal food and fuel production.
The world produces more than enough food, but there isn't political will to 1) ensure efficient crisis management and delivery and 2) provide development assistance sufficient to ensure production capabilities where needs are greatest. And then there are genocidal maniacs like Mugabe that ruins his countrys capability to stay self sufficient and uses the threat of starvation to control his opposition.
Because that was for async bus operation, not async internal operation. The 68000 is fully synchroneous internally, as most/all other commercially successfull CPU's. Async buses is nothing new, and the ability to support it on the 68000 was in fact mostly to allow it to integrate with older hardware.
But for any of this to have ANY value, the people in question needs to have seriously considered all the available data and acurately predicted the outcome. The number of people who regularly lose money on stock markets, and even more so the number of people who gamble with no basis in fact should indicate that it's unlikely to be a great indicator. Even more if the people involved are self selected, in which case the chance is high that the numbers are influenced by a number of people who are unreasonably sure about their choice because of personal convictions.
While many VC's did catastrophic investments, most of them are VERY good at protecting their investments from ending in the founders pockets until they've sold out, or the company has gone public. I'm sure a portion of dot-com founders that burned their VC's badly still managed to get out with lots of cash, particularly for companies that survived until some time after an IPO, but the majority likely were stuck with peanuts.
Proper strategic planning can be learnt. Project management can be learnt. Business analysis can be learnt. Basics like learning methods for cost benefits analysis (i.e. not selling at a loss isn't always easy to avoid if the product or service is complex unless you actually spend some time figuring out how much it costs you to provide it), risk analysis, good hiring practices, basic accounting (good for staying out of jail...).
Most of "entrepeneurship" is just about having some skills in a wide variety of areas, and knowing how to look for oppotunities, though ome people make do with just being great at adapting.
I've worked in several startups, and co-founded three of them - the first time we made so many stupid mistakes you wouldn't believe it that could have trivially been avoided if any of us had learned a few of the skills mentioned above. In the next two I wasn't involved in the day to day running of the business, and that is perhaps the biggest regret I have for them, as I saw quite a few repeats of mistakes I'd made myself in my first startup. However I also saw the differences brought in by professional hires in areas of the business that actually had experience in some of those fields.
In a way it was a great experience, though painful, in that I've seen first hand what a difference different approaches makes, and I've learned a lot about what it takes to clean up problems that will otherwise eventually kill a business.
A lot of people will succeed in building a business that can feed them, but even more will fail, and vanishingly few will succeed in building a business that will grow large. The odds of success are badly against you to begin with. If you do aquire some of the skills mentioned you're at least improving your chance of being in the 10% or so that survives more than 3 years significantly.
My advice is take your time to prepare properly first. Yes, there are a lot of things you will need to pick up from experience, but you're much more likely to see your business live long enough to gain that experience if you're well prepared and have picked up some essential skills.
My second advice would be: Make sure you know when to quit and wind your business up in a responsible way. It's better to close down and try again later, that keep flogging a dead horse and burning yourself out. That includes even if your business can keep floating, but you are unhappy with returns and you don't see improvements at a reasonable rate (for YOUR definition of reasonable). Get a regular job, and look for the next opportunity when you're ready for it.
Sigh. No, it doesn't cover reading the file from the hardware because reading the initrd image is the job of the bootloader. Why don't you try learning a bit about the process before spouting crap?
The compile products (object files) easily blow out to twice that. And the compiler itself consumes a tremendous amount of memory assembling that object files. And then once you have the object files, the linker steps in, which also requires a tremendous amount of memory.
TCC doesn't need a separate linker - it can compile and link in one go straight to RAM. It doesn't need to assemble or output object files.
And no, writing to disk is not a requirement - try actually looking at TCCBOOT before you write about it.
You're right it takes a lot of RAM, but it doesn't really matter - this isn't exactly something most people will ever run for anything but testing. And this RAM requirement will be only until the kernel has been compiled, at which point the initrd image and all the RAM used for the compilation can be freed.
If you seriously think that the approximately 12.000 lines of TCCBOOT code is "most of an OS kernel" you need to have a long look at the core of the Linux kernel some day. Those 12.000 lines contains mostly gunzip, romfs support code, a malloc implementation and a math library.
Of that, less than 500 lines is the filesystem support.
You can do that with TCC, though not automatically. TCC comes with a library you can link with to compile C code and execute it at runtime, so you can use C as an extension language for your app and compile it as and when you need it.
Testing kernel changes "almost" on the fly can already be done to some extent by compiling the kernel separately, and then starting an emulator or user mode linux, but this could take it one step further.
Why does TCC require an already running kernel? The only facilities TCC needs is the ability to read source from somewhere, output binary code to somewhere, and allocate memory. All can trivially be supported with a tiny bit of support code. No need for a kernel.
Another option is system like Semantic Dictionary Encoding (M. Franz. Code-Generation On-the-Fly: A Key to Portable Software. PhD thesis, ETH Zurich, Mar. 1994. - It's available online on ETH's servers somewhere but I don't have time to dig it up) - which was (is?) in use by the Mac Oberon people to generate CPU independent binaries.
TCC is an incredibly tiny compiler with practically no dependencies on the environment. It's based on a cleaned up entry to the obfuscated C contest. So you can safely assume it's using every dirty trick in the book and then some. It still sounds incredible though.