Sorry, but I'm opposed to the death penalty. So you'll just have to accept that they will have a life sentence, with 8 hours of waterboarding every day.
Re:Sandisk Micro and multi-partition support
on
Flash Drive Roundup
·
· Score: 1
Mine do not show up as two devices. I'm using a vanilla Linux setup, so if only one USB device is presented to the USB bus, I'll only get once device in the kernel, and only one device node will be available for the whole device. Partition devices will show up, as partitioned, but so far there has been only one such device and it has always been FAT formatted (or is that FAT32?). Maybe you are getting an extra device based on the partition?
I then make a compressed archive of the entire device contents, and write onto it a pre-built drive image that contains a partition table with one Linux (type 83) partition pre-formatted with ext2.
I don't know what is recorded on your devices. Mine show up with one partition and it's empty. There's no software. There are no files. Maybe I'm missing something? But the package labeling does not say there is any software, either.
Once a drive is inserted, if other software acts on the drive, it's certainly possible for that software to locate ISO files and loopback mount them and they show up as CD devices. I've never seen this before, but based on some things I have seen, this would not be hard for programmers to do. Note that such "drives in files" would not be available to the BIOS to boot from, unless the BIOS also has this trick coded into it.
I have seen a BIOS that, when booting from a USB device that had an ISO image written directly on it at sector 0 (e.g. someone used "dd" or equivalent to copy an ISO file to the USB device), that BIOS engaged CD/DVD emulation, and performed an El Torito style boot just as it would from a real bootable CD/DVD. Then it would be up to the kernel and/or its initrd code to find the ISO image on a HD-like device (since it's just a HD to the kernel) and mount it (FYI... Ubuntu's casper initialization system will succeed at this). But I don't know that this is what you are running into.
Are we even talking about the same kind of devices? I have SanDisk brand Cruzer product devices in 2GB, 4GB, 8GB, and 16GB sizes. Is that what you have?
Both means should be provided. That way we can still have SSD devices emulating regular hard drives. But even if the direct layer access is not provided, a standard command code to identify block sizes, and a standard command code to erase a block (e.g. discard it from wear leveling translation for now) would be partly useful. One could erase all the blocks and thus reset the wear leveling over the whole device. Of course, you better have a few backup copies of the data.
Power management can turn off sections of the flash memory. This is good, of course, to reduce battery consumption in laptops and netbooks. But the process of turning a section's power off and then turning another section's power on can slow down the access. With very random access, expect that to simply happen a lot. So random hopping around the storage, while not as slow as a mechanical hard drive, will be slower than sequential.
Add wear leveling into the picture and you have a layer of memory translation. The purpose is to select different blocks out of a pool each time an erase needs to be done. So if you write over the same page of storage a million times, it is actually erasing a number of different blocks. In real world writing, which has its own random access, the end result over time is that this translation layer has the data scattered all over the available space.
Now even a sequential access to the data is really accessing the data in a random order based on what the wear leveling translation layer state is. This increases the number of times the access transitions from power controlled section to another. If the design is one where few or even one section can be powered on at the same time, this slows things down even for a sequential access. If the design allows many or even all sections to power on at the same time, then it shouldn't slow down (just for sequential reading), but would increase the power drawn and shorten battery charge/life if on battery power.
What would be useful... if you don't mine occasionally losing all your data... would be some kind of reset operation that can be done to the whole SSD device to discard and re-initialize the wear leveling translation (but not discard the bad blocks data). You could sequentially write over the whole device, which will help some, but won't be a complete re-initialization. The OS needs to be writing to the device in units of at least the erase block size in order to do this right. Multiple whole writes might do better than just one, but this is accumulating more wear on most (or if enough passes is done, perhaps just two... all) blocks.
No... get paid the lesser of the current pay at the current company or the new pay at the new company based on its offer. The offering company would be obligated to pay that rate if the current company decided to not enforce the non-compete.
So, people should not have the right to agree to sell certain rights?
Did he FREELY sell those rights for an identifiable compensation? Or was he coerced into something that clearly takes away right, by not having a choice (e.g. sign this or no job)? If EMC's intent was STRICTLY to be sure trade secrets are not divulged, then why didn't they just ask him to sign an agreement for that? The reality is these clauses are abusive because they go beyond what the companies are claiming they protect. These clauses are intended to entrap people to keep pay levels lower, reducing the competition. EMC did not negotiate in good faith. EMC should pay him his full salary for the period (12 months in this case) it wants to control how he makes a living.
Suppose someone were going to pay me 2 years worth of money, up front, for 1 year of work, in exchange for not competing for a year.
That's not what EMC did in this case. It was continuing employment. What you are saying is the equivalent of EMC paying him 12 months of salary to sit out... not in advance like your suggested situation, but at the end of the continuing employment. If we make the law require people to be paid their original salary for the period they are denied work where they otherwise could get work in their field, by the employer denying it, then that changes things. It's about the money.
... take no prisoners. Do not pass GO, do not collect $200. Do not deal out of court. Get that judgment and force them to lose their way all the way to SCOTUS.
All autorun needs to be done only from trusted sources. The program to be run needs to have a cryptographic strength signature. The computer keeps a set of public keys to allow autorun. Microsoft would supply their own key to get this started (which means this computer initially will only autorun anything Microsoft signed). And this applies to the entire media, so if a script runs an executable, the malware perps cannot just substitute the executable. So basically, nothing on the inserted media can be run unless everything on that media is signed, AND signed by the same key (in case it is signed by another key the user has added). Also, these keys need to be kept encrypted with access only by a user passphrase. Any attempt to add a key definitely needs some user prompting. And there is no reason to treat even a non-recordable CD/DVD any differently. Only the boot device gets to run things without a prompt (which does mean there is still exposure for computers in which the media is the first boot device when the user reboots with it left inside... that's another issue to deal with).
I would not expect anyone to manually type the mapped URLs. I could provide a system where users could request a shorter mapping for a given page if they want to put a reference to it somewhere that shorter is a plus, such as in physical print where typing would be needed. I might limit this to logged in users.
I would not be using base 64 character encoding. I don't want to risk what might be generated. I might go as far as base 24 (10 digits and 14 letters) which shouldn't generate anything really bad in English and can work in 35 characters for a 160 bit checksum.
There's no monstrosity to this at all. But, just so you can sleep better, it is for my own site. However, if someone wanted to do the same thing, or otherwise wanted to achieve the goals I'm trying to do (have URL generators pass parameters to URL requests, but not let those parameters bloat the URL, and keep the URL within reasonable size, even if not small enough for humans to memorize), I'd offer the code. It will be open source. It would let other programs that generate URLs with parameters not worry about URL length limits.
Doing serial numbers requires constant synchronization between all the servers for EVERY URL being generated. No thanks. Adding a new URL indexed by its checksum can be Asynchronously spread through the web servers. When a request fails to find one being requested, it can query another database as a fallback. Things that work asynchronously are better.
Actually, it could be shorter. The full SHA1 checksum would not need to be used. That's where the dynamic collision checking comes in. If a checksum collides, it is lengthened.
Additionally, this is NOT about making a URL shorter that something someone else might do. It's about making extremely long URLs (that encode lots of request parameters that would be generated by code elsewhere that is making links) into URLs that are just not so damned long. These are not URLs people can memorize like 6 character ones that tinyurl used to do. It's more about making a URL that can, if need be, safely pasted somewhere, and would display in whole in the URL bar.
The notification would apply to any shortened checksum. So if I shorten it too much, it tells me. And that's how I would test the code: extreme short checksum.
Unfortunately, it's not yet an integral part of web frameworks that I have seen. So I am adding it in a new web site I'm building. It means I have to add the feature to the web server.
It works like this. Every part of the web site code that builds URLs for the same site passes them first through the mapping logic. This basically builds an SHA1 checksum of the canonicalized URL string. Then it looks up the string in a fast database (I'll be using Berkeley DB for this). If it's already there, and is the same URL, it generates a new URL that references the checksum. If it was a different URL, it notifies me that it found an SHA1 collision. If not already there, it adds it. The original URL is thus replaced with the mapping URL.
Code added to the web server will be designed to detect checksum URLs. If it looks like one, it looks it up in the database to get the original URL, and proceeds with the request using that URL. Original URLs would still be processed as usual, in case they leak out, or are intentionally made to bypass the mapping for special purposes. Basically it's like a tiny URL service, but integrated without the need to do a redirect.
One thing I am looking at doing is shortening even these URLs, even though they should be short enough already. But this raises the chance for a collision to the point I'll need to add logic to deal with it. How I would do that is similar to a hash data structure collision, but by expanding on the SHA1 checksum by adding back digits that were removed to shorten it.
External URLs to other sites can be done the same way. This does add the extra redirection. I could limit the use of this only to long external links, since this being a web interface, should handle long external links OK. It could be an option.
Slashdot Mirror
It also takes a LOT longer time if you don't develop the software properly using standard programming interfaces and make sure it is portable.
But the ones that can't make it in private practice and have to get a government job are the most clueless of all.
Sorry, but I'm opposed to the death penalty. So you'll just have to accept that they will have a life sentence, with 8 hours of waterboarding every day.
Mine do not show up as two devices. I'm using a vanilla Linux setup, so if only one USB device is presented to the USB bus, I'll only get once device in the kernel, and only one device node will be available for the whole device. Partition devices will show up, as partitioned, but so far there has been only one such device and it has always been FAT formatted (or is that FAT32?). Maybe you are getting an extra device based on the partition?
I then make a compressed archive of the entire device contents, and write onto it a pre-built drive image that contains a partition table with one Linux (type 83) partition pre-formatted with ext2.
I don't know what is recorded on your devices. Mine show up with one partition and it's empty. There's no software. There are no files. Maybe I'm missing something? But the package labeling does not say there is any software, either.
Once a drive is inserted, if other software acts on the drive, it's certainly possible for that software to locate ISO files and loopback mount them and they show up as CD devices. I've never seen this before, but based on some things I have seen, this would not be hard for programmers to do. Note that such "drives in files" would not be available to the BIOS to boot from, unless the BIOS also has this trick coded into it.
I have seen a BIOS that, when booting from a USB device that had an ISO image written directly on it at sector 0 (e.g. someone used "dd" or equivalent to copy an ISO file to the USB device), that BIOS engaged CD/DVD emulation, and performed an El Torito style boot just as it would from a real bootable CD/DVD. Then it would be up to the kernel and/or its initrd code to find the ISO image on a HD-like device (since it's just a HD to the kernel) and mount it (FYI ... Ubuntu's casper initialization system will succeed at this). But I don't know that this is what you are running into.
Are we even talking about the same kind of devices? I have SanDisk brand Cruzer product devices in 2GB, 4GB, 8GB, and 16GB sizes. Is that what you have?
Both means should be provided. That way we can still have SSD devices emulating regular hard drives. But even if the direct layer access is not provided, a standard command code to identify block sizes, and a standard command code to erase a block (e.g. discard it from wear leveling translation for now) would be partly useful. One could erase all the blocks and thus reset the wear leveling over the whole device. Of course, you better have a few backup copies of the data.
Power management can turn off sections of the flash memory. This is good, of course, to reduce battery consumption in laptops and netbooks. But the process of turning a section's power off and then turning another section's power on can slow down the access. With very random access, expect that to simply happen a lot. So random hopping around the storage, while not as slow as a mechanical hard drive, will be slower than sequential.
Add wear leveling into the picture and you have a layer of memory translation. The purpose is to select different blocks out of a pool each time an erase needs to be done. So if you write over the same page of storage a million times, it is actually erasing a number of different blocks. In real world writing, which has its own random access, the end result over time is that this translation layer has the data scattered all over the available space.
Now even a sequential access to the data is really accessing the data in a random order based on what the wear leveling translation layer state is. This increases the number of times the access transitions from power controlled section to another. If the design is one where few or even one section can be powered on at the same time, this slows things down even for a sequential access. If the design allows many or even all sections to power on at the same time, then it shouldn't slow down (just for sequential reading), but would increase the power drawn and shorten battery charge/life if on battery power.
What would be useful ... if you don't mine occasionally losing all your data ... would be some kind of reset operation that can be done to the whole SSD device to discard and re-initialize the wear leveling translation (but not discard the bad blocks data). You could sequentially write over the whole device, which will help some, but won't be a complete re-initialization. The OS needs to be writing to the device in units of at least the erase block size in order to do this right. Multiple whole writes might do better than just one, but this is accumulating more wear on most (or if enough passes is done, perhaps just two ... all) blocks.
... the most commonly confused people in the world?
And what if he had appointed Richard Stallman?
Yup. Slashdot needs to be fixed so it doesn't redirect back to the unencrypted URL. This is the real Slashdot, right? I hope.
... that all internet communications needs to be done over encrypted connections or sessions
And they are financing all this legal work how? Taxpayer bailout? Oh, yeah, sue the people that are paying them to sue people. Nice work.
... I sure had to do one this evening.
No ... get paid the lesser of the current pay at the current company or the new pay at the new company based on its offer. The offering company would be obligated to pay that rate if the current company decided to not enforce the non-compete.
So, people should not have the right to agree to sell certain rights?
Did he FREELY sell those rights for an identifiable compensation? Or was he coerced into something that clearly takes away right, by not having a choice (e.g. sign this or no job)? If EMC's intent was STRICTLY to be sure trade secrets are not divulged, then why didn't they just ask him to sign an agreement for that? The reality is these clauses are abusive because they go beyond what the companies are claiming they protect. These clauses are intended to entrap people to keep pay levels lower, reducing the competition. EMC did not negotiate in good faith. EMC should pay him his full salary for the period (12 months in this case) it wants to control how he makes a living.
Suppose someone were going to pay me 2 years worth of money, up front, for 1 year of work, in exchange for not competing for a year.
That's not what EMC did in this case. It was continuing employment. What you are saying is the equivalent of EMC paying him 12 months of salary to sit out ... not in advance like your suggested situation, but at the end of the continuing employment. If we make the law require people to be paid their original salary for the period they are denied work where they otherwise could get work in their field, by the employer denying it, then that changes things. It's about the money.
... take no prisoners. Do not pass GO, do not collect $200. Do not deal out of court. Get that judgment and force them to lose their way all the way to SCOTUS.
All autorun needs to be done only from trusted sources. The program to be run needs to have a cryptographic strength signature. The computer keeps a set of public keys to allow autorun. Microsoft would supply their own key to get this started (which means this computer initially will only autorun anything Microsoft signed). And this applies to the entire media, so if a script runs an executable, the malware perps cannot just substitute the executable. So basically, nothing on the inserted media can be run unless everything on that media is signed, AND signed by the same key (in case it is signed by another key the user has added). Also, these keys need to be kept encrypted with access only by a user passphrase. Any attempt to add a key definitely needs some user prompting. And there is no reason to treat even a non-recordable CD/DVD any differently. Only the boot device gets to run things without a prompt (which does mean there is still exposure for computers in which the media is the first boot device when the user reboots with it left inside ... that's another issue to deal with).
... err ... I mean without virus protection. Let's see just how safe the OS ... by itself ... really is.
So are you saying the judge is gay?
... the cops that caused a city wide panic because they misunderstood a few funny lighted signs?
I would not expect anyone to manually type the mapped URLs. I could provide a system where users could request a shorter mapping for a given page if they want to put a reference to it somewhere that shorter is a plus, such as in physical print where typing would be needed. I might limit this to logged in users.
I would not be using base 64 character encoding. I don't want to risk what might be generated. I might go as far as base 24 (10 digits and 14 letters) which shouldn't generate anything really bad in English and can work in 35 characters for a 160 bit checksum.
There's no monstrosity to this at all. But, just so you can sleep better, it is for my own site. However, if someone wanted to do the same thing, or otherwise wanted to achieve the goals I'm trying to do (have URL generators pass parameters to URL requests, but not let those parameters bloat the URL, and keep the URL within reasonable size, even if not small enough for humans to memorize), I'd offer the code. It will be open source. It would let other programs that generate URLs with parameters not worry about URL length limits.
Doing serial numbers requires constant synchronization between all the servers for EVERY URL being generated. No thanks. Adding a new URL indexed by its checksum can be Asynchronously spread through the web servers. When a request fails to find one being requested, it can query another database as a fallback. Things that work asynchronously are better.
Actually, it could be shorter. The full SHA1 checksum would not need to be used. That's where the dynamic collision checking comes in. If a checksum collides, it is lengthened.
Additionally, this is NOT about making a URL shorter that something someone else might do. It's about making extremely long URLs (that encode lots of request parameters that would be generated by code elsewhere that is making links) into URLs that are just not so damned long. These are not URLs people can memorize like 6 character ones that tinyurl used to do. It's more about making a URL that can, if need be, safely pasted somewhere, and would display in whole in the URL bar.
The notification would apply to any shortened checksum. So if I shorten it too much, it tells me. And that's how I would test the code: extreme short checksum.
Unfortunately, it's not yet an integral part of web frameworks that I have seen. So I am adding it in a new web site I'm building. It means I have to add the feature to the web server.
It works like this. Every part of the web site code that builds URLs for the same site passes them first through the mapping logic. This basically builds an SHA1 checksum of the canonicalized URL string. Then it looks up the string in a fast database (I'll be using Berkeley DB for this). If it's already there, and is the same URL, it generates a new URL that references the checksum. If it was a different URL, it notifies me that it found an SHA1 collision. If not already there, it adds it. The original URL is thus replaced with the mapping URL.
Code added to the web server will be designed to detect checksum URLs. If it looks like one, it looks it up in the database to get the original URL, and proceeds with the request using that URL. Original URLs would still be processed as usual, in case they leak out, or are intentionally made to bypass the mapping for special purposes. Basically it's like a tiny URL service, but integrated without the need to do a redirect.
One thing I am looking at doing is shortening even these URLs, even though they should be short enough already. But this raises the chance for a collision to the point I'll need to add logic to deal with it. How I would do that is similar to a hash data structure collision, but by expanding on the SHA1 checksum by adding back digits that were removed to shorten it.
External URLs to other sites can be done the same way. This does add the extra redirection. I could limit the use of this only to long external links, since this being a web interface, should handle long external links OK. It could be an option.