Mechanical HDDs are a current non-volatile rewritable storage technology. For that matter, HDDs don't use moving parts to read or write the data (they use moving parts to address different bits of storage).
Anyway, this is probably a protocol (and connector quality) standard, rather than a media technology. It's essentially SD with longer addresses and faster transmission. In principle, you could have a mechanical HDD in this format (you can actually get CF-format HDDs, so why not, aside from the insanity of trying to move things around in 1mm minus packaging?).
I'd hope it's signed with a key you already have from Microsoft, and has an MD5 sum that Microsoft has published on their site. If so, you can be pretty certain that you're getting the same thing that they put out. Considering that your connection to microsoft.com is going over a similarly untrusted network, you should be using similarly paranoid checks on that.
OSRM's deal, last time I heard was that they were going to pay for fighting your lawsuit in the event you got sued. They believe that Linux is actually fine to use, but unscrupulous companies might come after you with lawsuits in hopes of getting you to settle. OSRM is offering to fund your lawsuit for you if one occurs. This indicates that they have found 283 patents that Linux could be argued to violate, but all of them don't really apply to Linux or are invalid.
The reason we should look favorable on OSRM is that they are trying to make sure that, if there is a lawsuit involving Linux at some point, that the Linux side will win rather than settling.
Don't use stored procedures in your initial design. But also don't rule them out in your original design. Once you've implemented your application, remember that stored procedures are available as an optimization technique, if the portion which turns out to be slow is amenable.
There are trade-offs involved in using stored procedures; primarily that they are separate from your application code and therefore that two parts have to agree, and that it is more effort to modify stored procedures. They should therefore be used only if and when they provide a necessary benefit.
If your design rules out stored procedures, you'll probably have performance problems at some point. If you use stored procedures all the time, your DBA will never get a chance to optimize them (and the rest of the database), because you'll be constantly needing them tweaked.
It is actually worthwhile having stored procedures duplicate application logic when you use them, because then you can test their results against each other, and your application developers can follow what is going on; otherwise your developers will keep bugging your DBA and prevent her from getting anything done, you'll have to have someone less skillful write stuff while she visits relatives in China, etc. (not that I have any experience in this...)
Re:The future sucks, it always does
on
Feed
·
· Score: 2, Interesting
I'd suggest reading some Kim Stanley Robinson. His futures are much more reasonable than most SF; the changing technology tears society apart because of how different things become, but people muddle through it. Both fascism and free love get tried, and neither is ultimately stable. There are no endings, happy or otherwise; the answers to one day's problems are wrong the next day.
The natural consequence of progress along any dimension always seems like madness to the people from before and requires adaptations which may not be desired. PK Dick just focuses on people who don't adapt.
The Unix filesystem also has a directory structure, which is great for a lot of things, but not sufficiently flexible for the things that people use more than 1G of storage for these days. I'm proposing a filesystem where there are just inodes and nothing else; the kernel will list all the inodes for helper code and will give access to files by inode, and making sense of the collection is left to other code.
The kernel would have a way of listing all of the handles, and you'd have, at least, a listing by date that you could use to retrieve any file. So you don't have to worry about leaking space, because there are always references.
(Obviously, this is equivalent to having a filesystem with a root directory and no other support for directories. But not having subdirectories simplifies the design, anyway)
Multithreading is, in general, not trivial. But if you already have the problem broken up into an array of problems each of which can be solved independantly, which is what you need in order to use a vector processor, then it is really easy to multithread. If fact, you can do it with fork and wait.
Re:Can arrow key history be like Matlab's?
on
Bash 3.0 Released
·
· Score: 1
Or use "man bash", which actually explains the builtins. "man bash\n/fc\n/\n/\n" turns up a nice explanation with more detail.
I think the important advance of the book user interface is that, when you act to get more text, you know immediately where the next text begins, because all of the text now visible is new. I don't think that it is necessary to have two surfaces visible at the same time, but I think that having pages rather than scrolling text is vital to making the technology transparent to the user.
If you really want a vector-processor supercomputer you can program in Fortran, get yourself a G5 and gcc. The PPC64 supports SIMD vector processing. For that matter, any problem which benefits from vector processing is trivial to parallelize with threads.
The article said that people thought an actual email from the FTC was fraudulent. I'm fairly sure that the FTC has never sent me a legitimate email. For that matter, any email of this sort that I'm not expecting in almost certainly fraudulent, especially if some third party doing a survey knows about it.
The closest I can imagine to them actually having a legitimate email in this survey is if they paid participants during the study using their PayPal accounts, such that money had actually been deposited in people's accounts like the email said.
I think the best thing would be to have a filesystem which didn't have any built-in organization, but let the organization be handled separately. You associate each file with a 128-bit binary handle. You can also add indirection by having handles that refer to each other. All the organization which makes this useful would be in libraries and daemons or kernel modules which associate handles with other things.
This allows arbitrary organization methods to be added later, and makes it convenient for programs to apply their own local organizations.
The way Linux does encrypted storage is with encrypted devices rather than encrypting the filesystem on the device. This is good because it means you can encrypt any (device-backed) filesystem.
The simple answer is that they first write the change to a journal; if it doesn't make it there completely and correctly, it will be backed out. Once it is written there, the filesystem is changed, and the new version will be seen instead of the old version. At that point, the in-place version of the data can be updated; no matter what is done to it, it can be recovered from the journal, which is authoritative. Once the in-place version is updated correctly, the record can be dropped from the journal.
So, essentially, the content is doubled, but only for the most recent stuff where there is a new and an old version to keep track of. Once something is done changing (or has been replaced again) the duplicate is freed, since it doesn't matter any more.
At my work we design the boards with LEDs and test points attached to the extra microcontroller pins. You can get a lot of information out of an LED just looking at it, if you can assign it to whatever use you happen to wait at the moment.
1. He's absolutely right. You don't need to be able to write code (or that particular code) in order to identify problems and have suggestions about designs. People writing code benefit from the advice of others.
2. In my experience, this misses the point, but the original myth does as well. The real reason to go under the hood is not to fix anything, but to figure out what's really going on. Chances are you won't change the actual code, but you may change how you're using it to account for its behavior. It's often really useful to be able to trace into provided code in order to resolve ambiguities in the documentation.
3. He makes the mistake of assuming a direct connection between the people who end up using software and the people who initially commission it. It is common and getting more common that a developer will be employed by someone who wants some software to exist but doesn't care who else gets it. They may intend to use it as part of their process, use it to enable them to sell hardware, or use it to enable them to sell other software. In all of these cases, OSS means that the company's employees don't have to do all the work.
4. This myth is widely cited as something that OSS people think by non-OSS people. But I haven't actually heard anyone seriously claim anything more than that particular projects are better than particular products.
5. Developers have a wide variety of hobbies and a wide variety of needs. Developers' itches do include things like personal accounting software and image manipulation tools. The problem with the GIMP is not that it isn't someone's itch, but that user interface designers and Photoshop users are intimidated by the need to code in order to affect the project. See #1; if some graphic designers unhappy with Photoshop's price tag explained in detail how the GIMP should work, and the GIMP developers were willing to take this advice, the GIMP could get over its unusability. For that matter, a graphic design firm could hire developers for the GIMP to make it suitable for their use.
6. I agree with this. Give users the ability to select a program by name and the ability to ask for someone else's choice of a program by function. For that matter, include a button for "This web browser is driving me crazy. Give me a different one."
On the first point, I think that to most people "bold" and "italic" are more descriptive terms for the semantics than "strong" and "emphatic", even if the "bold" content were formatted in all caps and the "italic" content were underlined. For that matter, the defintion of emphatic in Webster's includes "strong". Obviously, those terms are not particularly contrastive.
For point two, you're missing the point. In order for the quotation to be accurate, the text which was bold must be bold. If I'm citing an unusual use of bold text, it is part of the semantics that the text be bold.
What I want to know is why they didn't make "b" a synonym for "strong" and "i" a synonym for "em". Might as well make use of the one-letter tags that people know. Of course, this would change the effects of nested "i" tags, and may surprise the occasional person when they find that "i" comes out as underline in a manuscript.
Of course, there's also the issue of how to quote formatted text. What am I supposed to do if I want to transcribe a letter I got on paper where the author used bold for something? What if I want to point out that they used bold for a book title, where it wouldn't be an accurate representation of the quotation to use the accurate content tag, and would be entirely inappropriate to use a content tag which happens to tend to give the formatting which the letter used?
Assuming your congressmen aren't on any relevant committees, you don't get any say in the process until step 8; between steps 7 and 8 is when you want to make your position known.
On the other hand, I'm disturbed that someone from the Library of Congress thinks this wouldn't be a huge disaster. You can worry about the Executive Branch at any time.
What they should do is offer people the opportunity to buy a legitimate copy of the album in advance of the album actually being released. If you do the pre-order, you're also cleared to download the leaked version if you're impatient. If the reason to release the album early is to give fans a chance to pay for it when they first hear it, they might as well give the fans that chance without rushing the distribution channels. If both are available at the same time, the reason to buy it from iTunes instead of downloading it from P2P is to have the right to have it, not because Apple's packets are somehow more pleasing than other people's. So there's no reason not to sell the right to have a copy without actually distributing a copy at the time, if the customer is willing to make their own arrangements until the album is officially released.
But slashdot says that having an RIAA contract is bad for artists. So people who download mp3s (illegally, I presume) are acting to help the artists avoid getting conned. This hurts the variety of mainstreet crap, but means better artists go to the indies where they can play interesting music.
Don't forget SCO v. Novell, which was dismissed but has been refiled with SCO actually making the necessary claims, but without further action. I believe that it is actually this case that SCO v. AutoZone is actually stayed pending, since the latter case has nothing to do with copyrights for Linux, but rather copyrights for things that SCO claims AutoZone used in migrating to Linux; according to Novell, SCO doesn't own those copyrights anyway. Red Hat v. SCO is based on SCO v. IBM, since it pertains to Linux copyrights.
Slashdot Mirror
Mechanical HDDs are a current non-volatile rewritable storage technology. For that matter, HDDs don't use moving parts to read or write the data (they use moving parts to address different bits of storage).
Anyway, this is probably a protocol (and connector quality) standard, rather than a media technology. It's essentially SD with longer addresses and faster transmission. In principle, you could have a mechanical HDD in this format (you can actually get CF-format HDDs, so why not, aside from the insanity of trying to move things around in 1mm minus packaging?).
I'd hope it's signed with a key you already have from Microsoft, and has an MD5 sum that Microsoft has published on their site. If so, you can be pretty certain that you're getting the same thing that they put out. Considering that your connection to microsoft.com is going over a similarly untrusted network, you should be using similarly paranoid checks on that.
OSRM's deal, last time I heard was that they were going to pay for fighting your lawsuit in the event you got sued. They believe that Linux is actually fine to use, but unscrupulous companies might come after you with lawsuits in hopes of getting you to settle. OSRM is offering to fund your lawsuit for you if one occurs. This indicates that they have found 283 patents that Linux could be argued to violate, but all of them don't really apply to Linux or are invalid.
The reason we should look favorable on OSRM is that they are trying to make sure that, if there is a lawsuit involving Linux at some point, that the Linux side will win rather than settling.
Don't use stored procedures in your initial design. But also don't rule them out in your original design. Once you've implemented your application, remember that stored procedures are available as an optimization technique, if the portion which turns out to be slow is amenable.
There are trade-offs involved in using stored procedures; primarily that they are separate from your application code and therefore that two parts have to agree, and that it is more effort to modify stored procedures. They should therefore be used only if and when they provide a necessary benefit.
If your design rules out stored procedures, you'll probably have performance problems at some point. If you use stored procedures all the time, your DBA will never get a chance to optimize them (and the rest of the database), because you'll be constantly needing them tweaked.
It is actually worthwhile having stored procedures duplicate application logic when you use them, because then you can test their results against each other, and your application developers can follow what is going on; otherwise your developers will keep bugging your DBA and prevent her from getting anything done, you'll have to have someone less skillful write stuff while she visits relatives in China, etc. (not that I have any experience in this...)
I'd suggest reading some Kim Stanley Robinson. His futures are much more reasonable than most SF; the changing technology tears society apart because of how different things become, but people muddle through it. Both fascism and free love get tried, and neither is ultimately stable. There are no endings, happy or otherwise; the answers to one day's problems are wrong the next day.
The natural consequence of progress along any dimension always seems like madness to the people from before and requires adaptations which may not be desired. PK Dick just focuses on people who don't adapt.
The Unix filesystem also has a directory structure, which is great for a lot of things, but not sufficiently flexible for the things that people use more than 1G of storage for these days. I'm proposing a filesystem where there are just inodes and nothing else; the kernel will list all the inodes for helper code and will give access to files by inode, and making sense of the collection is left to other code.
The kernel would have a way of listing all of the handles, and you'd have, at least, a listing by date that you could use to retrieve any file. So you don't have to worry about leaking space, because there are always references.
(Obviously, this is equivalent to having a filesystem with a root directory and no other support for directories. But not having subdirectories simplifies the design, anyway)
Multithreading is, in general, not trivial. But if you already have the problem broken up into an array of problems each of which can be solved independantly, which is what you need in order to use a vector processor, then it is really easy to multithread. If fact, you can do it with fork and wait.
Or use "man bash", which actually explains the builtins. "man bash\n/fc\n/\n/\n" turns up a nice explanation with more detail.
I think the important advance of the book user interface is that, when you act to get more text, you know immediately where the next text begins, because all of the text now visible is new. I don't think that it is necessary to have two surfaces visible at the same time, but I think that having pages rather than scrolling text is vital to making the technology transparent to the user.
If you really want a vector-processor supercomputer you can program in Fortran, get yourself a G5 and gcc. The PPC64 supports SIMD vector processing. For that matter, any problem which benefits from vector processing is trivial to parallelize with threads.
The article said that people thought an actual email from the FTC was fraudulent. I'm fairly sure that the FTC has never sent me a legitimate email. For that matter, any email of this sort that I'm not expecting in almost certainly fraudulent, especially if some third party doing a survey knows about it.
The closest I can imagine to them actually having a legitimate email in this survey is if they paid participants during the study using their PayPal accounts, such that money had actually been deposited in people's accounts like the email said.
I think the best thing would be to have a filesystem which didn't have any built-in organization, but let the organization be handled separately. You associate each file with a 128-bit binary handle. You can also add indirection by having handles that refer to each other. All the organization which makes this useful would be in libraries and daemons or kernel modules which associate handles with other things.
This allows arbitrary organization methods to be added later, and makes it convenient for programs to apply their own local organizations.
The way Linux does encrypted storage is with encrypted devices rather than encrypting the filesystem on the device. This is good because it means you can encrypt any (device-backed) filesystem.
The simple answer is that they first write the change to a journal; if it doesn't make it there completely and correctly, it will be backed out. Once it is written there, the filesystem is changed, and the new version will be seen instead of the old version. At that point, the in-place version of the data can be updated; no matter what is done to it, it can be recovered from the journal, which is authoritative. Once the in-place version is updated correctly, the record can be dropped from the journal.
So, essentially, the content is doubled, but only for the most recent stuff where there is a new and an old version to keep track of. Once something is done changing (or has been replaced again) the duplicate is freed, since it doesn't matter any more.
At my work we design the boards with LEDs and test points attached to the extra microcontroller pins. You can get a lot of information out of an LED just looking at it, if you can assign it to whatever use you happen to wait at the moment.
It all depends on who your car winks at. And using your car's headlights as eyes gives it a great excuse to stare a foot below women's eyes.
1. He's absolutely right. You don't need to be able to write code (or that particular code) in order to identify problems and have suggestions about designs. People writing code benefit from the advice of others.
2. In my experience, this misses the point, but the original myth does as well. The real reason to go under the hood is not to fix anything, but to figure out what's really going on. Chances are you won't change the actual code, but you may change how you're using it to account for its behavior. It's often really useful to be able to trace into provided code in order to resolve ambiguities in the documentation.
3. He makes the mistake of assuming a direct connection between the people who end up using software and the people who initially commission it. It is common and getting more common that a developer will be employed by someone who wants some software to exist but doesn't care who else gets it. They may intend to use it as part of their process, use it to enable them to sell hardware, or use it to enable them to sell other software. In all of these cases, OSS means that the company's employees don't have to do all the work.
4. This myth is widely cited as something that OSS people think by non-OSS people. But I haven't actually heard anyone seriously claim anything more than that particular projects are better than particular products.
5. Developers have a wide variety of hobbies and a wide variety of needs. Developers' itches do include things like personal accounting software and image manipulation tools. The problem with the GIMP is not that it isn't someone's itch, but that user interface designers and Photoshop users are intimidated by the need to code in order to affect the project. See #1; if some graphic designers unhappy with Photoshop's price tag explained in detail how the GIMP should work, and the GIMP developers were willing to take this advice, the GIMP could get over its unusability. For that matter, a graphic design firm could hire developers for the GIMP to make it suitable for their use.
6. I agree with this. Give users the ability to select a program by name and the ability to ask for someone else's choice of a program by function. For that matter, include a button for "This web browser is driving me crazy. Give me a different one."
On the first point, I think that to most people "bold" and "italic" are more descriptive terms for the semantics than "strong" and "emphatic", even if the "bold" content were formatted in all caps and the "italic" content were underlined. For that matter, the defintion of emphatic in Webster's includes "strong". Obviously, those terms are not particularly contrastive.
For point two, you're missing the point. In order for the quotation to be accurate, the text which was bold must be bold. If I'm citing an unusual use of bold text, it is part of the semantics that the text be bold.
What I want to know is why they didn't make "b" a synonym for "strong" and "i" a synonym for "em". Might as well make use of the one-letter tags that people know. Of course, this would change the effects of nested "i" tags, and may surprise the occasional person when they find that "i" comes out as underline in a manuscript.
Of course, there's also the issue of how to quote formatted text. What am I supposed to do if I want to transcribe a letter I got on paper where the author used bold for something? What if I want to point out that they used bold for a book title, where it wouldn't be an accurate representation of the quotation to use the accurate content tag, and would be entirely inappropriate to use a content tag which happens to tend to give the formatting which the letter used?
Assuming your congressmen aren't on any relevant committees, you don't get any say in the process until step 8; between steps 7 and 8 is when you want to make your position known.
On the other hand, I'm disturbed that someone from the Library of Congress thinks this wouldn't be a huge disaster. You can worry about the Executive Branch at any time.
What they should do is offer people the opportunity to buy a legitimate copy of the album in advance of the album actually being released. If you do the pre-order, you're also cleared to download the leaked version if you're impatient. If the reason to release the album early is to give fans a chance to pay for it when they first hear it, they might as well give the fans that chance without rushing the distribution channels. If both are available at the same time, the reason to buy it from iTunes instead of downloading it from P2P is to have the right to have it, not because Apple's packets are somehow more pleasing than other people's. So there's no reason not to sell the right to have a copy without actually distributing a copy at the time, if the customer is willing to make their own arrangements until the album is officially released.
But slashdot says that having an RIAA contract is bad for artists. So people who download mp3s (illegally, I presume) are acting to help the artists avoid getting conned. This hurts the variety of mainstreet crap, but means better artists go to the indies where they can play interesting music.
Don't forget SCO v. Novell, which was dismissed but has been refiled with SCO actually making the necessary claims, but without further action. I believe that it is actually this case that SCO v. AutoZone is actually stayed pending, since the latter case has nothing to do with copyrights for Linux, but rather copyrights for things that SCO claims AutoZone used in migrating to Linux; according to Novell, SCO doesn't own those copyrights anyway. Red Hat v. SCO is based on SCO v. IBM, since it pertains to Linux copyrights.
Being relaxed is always a factor, but most games also require attention as well, and it is the interplay of these that makes them interesting.