I don't agree with your premise, but the solution is a good one.
All a database requires is ACID^2 (Add,Change,Inquire,Delete,Atomicity,Consistency,I solation,Durability) the bugbear here is the 'Consistency' tag. Originally and properly this only really refers to referential integrity, but it has been gradually extended to include more and more of the user application. First off came column types and 'NOT NULL' and it's grown from there into the horrific mess that is MS T-SQL.
What you are doing is putting the application server into the database, code that often goes into libraries or special servers (and sometimes nowadays in 'web services'). Stored procedures and triggers are reasonable solution to the problem BUT do not define what an RDBMS is.
An RDBMS is something that solves the difficult ACID^2 problem and so provides a solid base for the application and application services. Once you have that base the application level consistancy (eg "the G/L must balance") becomes a lot easier.
So back to the top, MySQL isn't a true database when it doesn't have transactions, but as long as you choose a backend with transactions it most definitly is an RDBMS, but perhaps not an application server.
IIRC (It was a long time ago) you use a standard distribution (Gausian ? "Normal" ? The one that shows the graph for dice throws) and measure where the 95% point is. After some simple maths you get these percentages from a given sample size. The figure is pulled out of (erm) a hat to some extent but it's the normal way to map the sample size onto a linear proability of the result being correct.
The reason that upsteam is slower isn't a marketing choice where you could technically choose any combination of upstream and downstream channels. The problem for DSL is that at the exchange end you have lots of unshielded cables right next to each other. There will be crosstalk and interference between them. For the downstream this isn't a problem the signal power is high and the noise is low at the exchange and there's no crosstalk at the customer end as there are no other modems nearby. But the upstream is a pig, the exchange has to sort out the signal from the cheap and nasty freebee modem that the ISP provided while a hundred other lines try to drown it in crosstalk.
This is the reason that SDSL is so expensive, it has to be protected from crosstalk at the exchange end.
It's also a good reason to get a wires only ADSL service and buy yourself a good (ethernet connected) modem.
People are looking at the security in relation to IPv6 because it's about to be attacked. A certain OS version has been released with IPv6 enabled by default, therefor, the zombie wars are going to be speading soon.
If I wanted to look into this I'd look at some of the words that have been absorbed into race hate; eg, one that seems to have fallen off the radar is "Wog". It may have even originally been a term of respect "Worthy Oriental Gentleman" but that sounds sarcastic, at least today.
The other place is medicine; "moron" was a properly defined medical term at one time.
There's already a perfect solution to this problem, the remote-desktop or X terminal depending on your OS. The only problem is that with windows you have to buy a minor variation of the OS that's 5 times the price and still pay more for each desktop. So what you save on hardware you pay out three times over to Microsoft.
BTW: Current screens have speakers, USB ports and a CPU; "all" that may be needed is a tiny upgrade to the CPU and it'll be a "remote desktop" client. But for a "remote desktop" client to be useful Microsoft would have to stop screwing their customers...
UUID {0211F909-749D-5BE3-D841-56C5635688C0}
on
Censoring a Number
·
· Score: 1
{0211F909-749D-5BE3-D841-56C5635688C0}
It's a version 5, care to guess that the string was before hashing..
Because NTFS filesystem compression is horrible.
It has poor compression and slows down the filesystem viciously, mostly due to fragmentation; I've see 200000 fragments in a single file!
I think the compression algoritim it uses is ZLW, you're lucky to get 1.5:1 in the best cases.
There are other issues, like a 20Gb compressed file giving fake disk errors (on a drive with 40Gb of free space) but generally the poor compression and performance is enough to ensure that you don't want to use it.
That particular variant turns on the windows firewall at the first boot, just get rid of all the pop-ups and it's back to the windows you know and errr.... well, know.
There doesn't seem to be much info round here so here's the key points...
The data on the hard disk is encrypted using a completely random key. Each sector of the disk is encrypted with a different key, derived from the random key and the sector number. The random key is stored, encrypted, on the hard disk. There is a small piece of space at the start of the disk that is unencrypted. A Seagate provided boot sector starts up and asks for a password. The password MAY be used to decrypt a random password stored on a USB key. Either the entered password or the random password from the USB key is used to decrypt the random key that the hard disk is encrypted with. The random key is given to the hard drive firmware and the hard drive decrypts the drive sectors. The boot sector then executes the 'real' boot sector of the hard disk to boot ANY OS. If the OS doesn't know about the encryption APIs all it ever sees is the decrypted data.
The 'managment' features are achieved by having other copies of the random drive key encrypted with different user passwords or USB keys.
All this can be done in software BUT then would require driver support from the OS. The Seagate drives do NOT require encryption support from the OS.
No contest, hardware makers provide guarentees. An auto destruct process is likely to amplify a spin doctored FDIV bug into a flaming death Lithium battery bug. They're not stupid, they're in the business of making nearly bug free products so they don't get too many defective returns. Unlike certain software houses.
The only things unencrypted are the partition table and the pre-boot authentication and I haven't noticed any performance hit, disks are sloooow anyway.
Also it's actually MORE convenient that an uncrypted disk, I enter my user and password about three seconds after turning the machine on and go find some coffee; the machine is ready to use when I come back. Without the Single Sign On that comes with the encryption I enter my password about half way through the boot process.
After that you only have to worry about USB drives, CDRs and backups.
Their drivers won't be any better, still crash happy, still dangerous.
BUT, userspace drivers could allow us to kill and restart the driver when it crashes, keep the old slow ABI around so we don't have to bin the working hardware when the maker tells us to and put the driver behind a 'firewall' to prevent it seeing anything that would upset it.
I can see why they don't want to release the binary interface of the card; it's not like an ethernet card... "put bytes here and they go on the wire"... the "interface description" would be a complete description of how the card works and why it works that way. The "driver" and the "chipset" are two interwoven parts of the device. The choice as to which side of the AGP a particular function is executed is not fixed and depends on detailed design choices during the co-development of the driver and the chipset.
To try and put it clearly this interface is just like the interface between the different phases of GCC; the C-compiler syntax trees are the "interface" between the phases and could be described but it's not a fixed interface. The programs on the sides of the interface share code so that they know what will be sent and how it should work.
They are stuck here; they cannot release the drivers because of paper contracts; they cannot release the 'interface' because it would require an exact description of the driver to make sense of it; and violate the contract. If they release what they can they're just taking the piss.
IMO there are two choices that allow both sides to be happy
1) Usermode drivers
2) An opensource daughtercard.
A box for a usermode driver would need care. In some ways a process with a usermode driver would have to be very different (eg control of shared memory in OTHER processes, DMA access to memory). The support for restarting the driver would be very interesting.
The simple fact is that there is no hard line between 'software' and 'hardware' and if part of the 'hardware' actually runs on the host system I don't see a problem for open source. AS LONG AS the 'hardware' conforms to a published interface specification. There is IMO no difference between comforming to 'Usermode driver Version 1.1' and 'ATI I/O Port Version 12.43832' both have advantages and disadvantages but both are perfectly reasonable.
The current situation is not reasonable; the kernel interface between the driver and the rest of the kernel is like the GCC example above it's not "Interface version 1.1" it's "The driver module interface for kernel version 2.6.14-ac13" and because these graphic card are designed in part like 'winmodems' (so they can be both cheap and fast) the makers are basically screwed.
Number (2) would be an expensive little card that basically runs a lightweight version of the driver and means that everything on the host side can be open source and/or firmware blob. It in effect turns a 'winmodem' graphics card into a completely selfcontained one. (ie solve the problem by throwing moeny at it)
This depends A LOT on the software/hardware that you use.
1.1) Some variants work at the hardware level (Special cards, The new Seagate drives) they are OS independent.
1.2) Some software varients have drivers for multiple OSes (eg: CompuSec).
1.3) The initial boot screen should allow multiple users; the cost is around 50..100 bytes per user, at least one of these will probably be an IT administrator. It is possible to change any of the passwords or even safely re-encrypt the drive knowing only one password.
1.4) If the users are into yellow stickies then they need a keyfob that can be used to boot any computer they have access to. The keyfob belongs to them NOT the machine.
2.1) The encryption works at the block level, it's no more susceptible to corruption than an unencrypted disk EXCEPT for the key block. This block needs to be backed up once. (There is of course the possibility of driver bugs...)
2.2) Decryption of the whole drive SHOULD be possible before the OS starts from the initial boot screen or a special boot disk. This lets you run standard recovery tools.
2.3) The backup software should put the backups into secure archives; even without FDE. If the user wants to just copy the files onto a USB Drive NTFS file encryption should be sufficient.
3.1) Speed, yes it will slow the disk down; but disks are REALLY slow anyway. If this is a problem you need the hardware solutions.
3.2) Data loss is no more likely as long as you keep the primary hard disk keys safe; that's the key that's actually used to encrypt the hard disk. This key cannot be changed unless the user first decrypts and then re-encrypts the entire drive. (ie it takes hours!)
4) FDE ONLY protects the data in the event that the disk is 'misplaced' and only works if the machine gets turned off (no 'warm' suspend, but hibernate is ok). I would say it's only relevant if you or your company have a legal requirement to protect the data. If you have it's now fast becoming a 'reasonable measure' that you need a REALLY good reason to ignore.
But of course as "genuine annoyance" gets worse more people will say "fuck this" and either not bother or use something better. This means websites will continue to have to support the crap that is IE6 in addition to (the somewhat less crap that is) IE7 long into the future.
OTOH if M$ and Yahoo push hard enough everyone without XP or with a messed up GA will become a Firefox user.
This is worthless; moving licenses between machines is only any use in a perfect world. A world where you get twenty four hours notice before lighting fries your computer. In the real world the license (and the rest of the data) has to be recovered from a backup tape or a flash drive.
Sorry, won't work.
We've had three laptops go missing, they all had phone home software on them (homegrown, hidden and almost undetectable) but I didn't get a peep from them. I would say that most of the people who steal these things know better than to let them anywhere near the internet intact.
The guy from the monster raving loony party DOES have a chance at winning, if his votes get too high the "serious" candidates get nervous. God forbid that he wins, talk about media circus!!
This is called a 'chroot jail' or it might be just "running as another user" both of which can be easily setup using standard unix tools. While packaged chroot jails has been done for firefox even distributions that pride themselves on security don't seem to see them as any sort of requirement...
Correction
1) Didn't want to use sufficient resources, there's no way to recover costs. ...
3) You NEVER focus on the big problems, the marketing department is demanding a release before firefox gets it next major release so you pick the easy fruit. Tabs happen to be simple because of the fact that IE is embedable. So it take a long time to open a new tab, so what. A new skin to match the next OS release was already written, as luck would have it it han't been made public yet. Some of the CSS bugs are a tiny tweak to the source, but passing ACID2... no way.
The result IE7, the marketing department is happy, the CSS tweaks mean you can make a page that's crap in IE6 but okay in IE7 and a standard browser, so the spinners are happy. Everyone's happy, well everyone we listen to anyway.
Slashdot Mirror
I don't agree with your premise, but the solution is a good one.
All a database requires is ACID^2 (Add,Change,Inquire,Delete,Atomicity,Consistency,I solation,Durability) the bugbear here is the 'Consistency' tag. Originally and properly this only really refers to referential integrity, but it has been gradually extended to include more and more of the user application. First off came column types and 'NOT NULL' and it's grown from there into the horrific mess that is MS T-SQL.
What you are doing is putting the application server into the database, code that often goes into libraries or special servers (and sometimes nowadays in 'web services'). Stored procedures and triggers are reasonable solution to the problem BUT do not define what an RDBMS is.
An RDBMS is something that solves the difficult ACID^2 problem and so provides a solid base for the application and application services. Once you have that base the application level consistancy (eg "the G/L must balance") becomes a lot easier.
So back to the top, MySQL isn't a true database when it doesn't have transactions, but as long as you choose a backend with transactions it most definitly is an RDBMS, but perhaps not an application server.
IIRC (It was a long time ago) you use a standard distribution (Gausian ? "Normal" ? The one that shows the graph for dice throws) and measure where the 95% point is. After some simple maths you get these percentages from a given sample size. The figure is pulled out of (erm) a hat to some extent but it's the normal way to map the sample size onto a linear proability of the result being correct.
As everybody says, a sample size of 34 is tiny.This is the reason that SDSL is so expensive, it has to be protected from crosstalk at the exchange end.
It's also a good reason to get a wires only ADSL service and buy yourself a good (ethernet connected) modem.
People are looking at the security in relation to IPv6 because it's about to be attacked. A certain OS version has been released with IPv6 enabled by default, therefor, the zombie wars are going to be speading soon.
The other place is medicine; "moron" was a properly defined medical term at one time.
There's already a perfect solution to this problem, the remote-desktop or X terminal depending on your OS.
...
The only problem is that with windows you have to buy a minor variation of the OS that's 5 times the price and still pay more for each desktop. So what you save on hardware you pay out three times over to Microsoft.
BTW: Current screens have speakers, USB ports and a CPU; "all" that may be needed is a tiny upgrade to the CPU and it'll be a "remote desktop" client. But for a "remote desktop" client to be useful Microsoft would have to stop screwing their customers
{0211F909-749D-5BE3-D841-56C5635688C0}
..
It's a version 5, care to guess that the string was before hashing
Without that there is "Nothing to see", "Move along, move along"
Perhaps to http://compression.ca/act/act-calgary.html
It has poor compression and slows down the filesystem viciously, mostly due to fragmentation; I've see 200000 fragments in a single file!
I think the compression algoritim it uses is ZLW, you're lucky to get 1.5:1 in the best cases.
There are other issues, like a 20Gb compressed file giving fake disk errors (on a drive with 40Gb of free space) but generally the poor compression and performance is enough to ensure that you don't want to use it.
Elektra Entertainment Group
Virgin Records America
UMG Recordings
BMG Music
Sony BMG Music Entertainment
Thats "E", "V", "U", "B" and "S"
ummm how about V.U.B.E.S ?
Short and sweet <VBG>
That particular variant turns on the windows firewall at the first boot, just get rid of all the pop-ups and it's back to the windows you know and errr .... well, know.
http://support.microsoft.com/default.aspx?scid=kb; en-us;814847
WSUS is about the best you can do with anything resembling reliability.
There doesn't seem to be much info round here so here's the key points ...
The data on the hard disk is encrypted using a completely random key.
Each sector of the disk is encrypted with a different key, derived from the random key and the sector number.
The random key is stored, encrypted, on the hard disk.
There is a small piece of space at the start of the disk that is unencrypted.
A Seagate provided boot sector starts up and asks for a password.
The password MAY be used to decrypt a random password stored on a USB key.
Either the entered password or the random password from the USB key is used to decrypt the random key that the hard disk is encrypted with.
The random key is given to the hard drive firmware and the hard drive decrypts the drive sectors.
The boot sector then executes the 'real' boot sector of the hard disk to boot ANY OS.
If the OS doesn't know about the encryption APIs all it ever sees is the decrypted data.
The 'managment' features are achieved by having other copies of the random drive key encrypted with different user passwords or USB keys.
All this can be done in software BUT then would require driver support from the OS. The Seagate drives do NOT require encryption support from the OS.
No contest, hardware makers provide guarentees. An auto destruct process is likely to amplify a spin doctored FDIV bug into a flaming death Lithium battery bug. They're not stupid, they're in the business of making nearly bug free products so they don't get too many defective returns. Unlike certain software houses.
It's ok if you encrypt EVERYTHING and with the right software/hardware it's fast and easy.
o mpusec.html
If you use hardware encryption (eg those seagate drives) there is no measurable performance hit but you don't need even that with software like this:
http://www.ce-infosys.com/english/products/free_c
The only things unencrypted are the partition table and the pre-boot authentication and I haven't noticed any performance hit, disks are sloooow anyway.
Also it's actually MORE convenient that an uncrypted disk, I enter my user and password about three seconds after turning the machine on and go find some coffee; the machine is ready to use when I come back. Without the Single Sign On that comes with the encryption I enter my password about half way through the boot process.
After that you only have to worry about USB drives, CDRs and backups.
BUT, userspace drivers could allow us to kill and restart the driver when it crashes, keep the old slow ABI around so we don't have to bin the working hardware when the maker tells us to and put the driver behind a 'firewall' to prevent it seeing anything that would upset it.
I can see why they don't want to release the binary interface of the card; it's not like an ethernet card ... "put bytes here and they go on the wire" ... the "interface description" would be a complete description of how the card works and why it works that way. The "driver" and the "chipset" are two interwoven parts of the device. The choice as to which side of the AGP a particular function is executed is not fixed and depends on detailed design choices during the co-development of the driver and the chipset.
To try and put it clearly this interface is just like the interface between the different phases of GCC; the C-compiler syntax trees are the "interface" between the phases and could be described but it's not a fixed interface. The programs on the sides of the interface share code so that they know what will be sent and how it should work.
They are stuck here; they cannot release the drivers because of paper contracts; they cannot release the 'interface' because it would require an exact description of the driver to make sense of it; and violate the contract. If they release what they can they're just taking the piss.
IMO there are two choices that allow both sides to be happy
1) Usermode drivers
2) An opensource daughtercard.
A box for a usermode driver would need care. In some ways a process with a usermode driver would have to be very different (eg control of shared memory in OTHER processes, DMA access to memory). The support for restarting the driver would be very interesting.
The simple fact is that there is no hard line between 'software' and 'hardware' and if part of the 'hardware' actually runs on the host system I don't see a problem for open source. AS LONG AS the 'hardware' conforms to a published interface specification. There is IMO no difference between comforming to 'Usermode driver Version 1.1' and 'ATI I/O Port Version 12.43832' both have advantages and disadvantages but both are perfectly reasonable.
The current situation is not reasonable; the kernel interface between the driver and the rest of the kernel is like the GCC example above it's not "Interface version 1.1" it's "The driver module interface for kernel version 2.6.14-ac13" and because these graphic card are designed in part like 'winmodems' (so they can be both cheap and fast) the makers are basically screwed.
Number (2) would be an expensive little card that basically runs a lightweight version of the driver and means that everything on the host side can be open source and/or firmware blob. It in effect turns a 'winmodem' graphics card into a completely selfcontained one. (ie solve the problem by throwing moeny at it)
So where's the usermode video driver project?
This is much more effective:
# cp /dev/zero /dev/hda
# Linux (devices depend on Unix variant)
http://www.youtube.com/watch?v=3OmpnfL5PCw
This depends A LOT on the software/hardware that you use.
...)
1.1) Some variants work at the hardware level (Special cards, The new Seagate drives) they are OS independent.
1.2) Some software varients have drivers for multiple OSes (eg: CompuSec).
1.3) The initial boot screen should allow multiple users; the cost is around 50..100 bytes per user, at least one of these will probably be an IT administrator. It is possible to change any of the passwords or even safely re-encrypt the drive knowing only one password.
1.4) If the users are into yellow stickies then they need a keyfob that can be used to boot any computer they have access to. The keyfob belongs to them NOT the machine.
2.1) The encryption works at the block level, it's no more susceptible to corruption than an unencrypted disk EXCEPT for the key block. This block needs to be backed up once. (There is of course the possibility of driver bugs
2.2) Decryption of the whole drive SHOULD be possible before the OS starts from the initial boot screen or a special boot disk. This lets you run standard recovery tools.
2.3) The backup software should put the backups into secure archives; even without FDE. If the user wants to just copy the files onto a USB Drive NTFS file encryption should be sufficient.
3.1) Speed, yes it will slow the disk down; but disks are REALLY slow anyway. If this is a problem you need the hardware solutions.
3.2) Data loss is no more likely as long as you keep the primary hard disk keys safe; that's the key that's actually used to encrypt the hard disk. This key cannot be changed unless the user first decrypts and then re-encrypts the entire drive. (ie it takes hours!)
4) FDE ONLY protects the data in the event that the disk is 'misplaced' and only works if the machine gets turned off (no 'warm' suspend, but hibernate is ok). I would say it's only relevant if you or your company have a legal requirement to protect the data. If you have it's now fast becoming a 'reasonable measure' that you need a REALLY good reason to ignore.
I see sarchasm
But of course as "genuine annoyance" gets worse more people will say "fuck this" and either not bother or use something better.
This means websites will continue to have to support the crap that is IE6 in addition to (the somewhat less crap that is) IE7 long into the future.
OTOH if M$ and Yahoo push hard enough everyone without XP or with a messed up GA will become a Firefox user.
This is worthless; moving licenses between machines is only any use in a perfect world. A world where you get twenty four hours notice before lighting fries your computer. In the real world the license (and the rest of the data) has to be recovered from a backup tape or a flash drive.
Sorry, won't work.
We've had three laptops go missing, they all had phone home software on them (homegrown, hidden and almost undetectable) but I didn't get a peep from them. I would say that most of the people who steal these things know better than to let them anywhere near the internet intact.
The guy from the monster raving loony party DOES have a chance at winning, if his votes get too high the "serious" candidates get nervous. God forbid that he wins, talk about media circus!!
This is called a 'chroot jail' or it might be just "running as another user" both of which can be easily setup using standard unix tools. While packaged chroot jails has been done for firefox even distributions that pride themselves on security don't seem to see them as any sort of requirement...
1) Didn't want to use sufficient resources, there's no way to recover costs.
3) You NEVER focus on the big problems, the marketing department is demanding a release before firefox gets it next major release so you pick the easy fruit. Tabs happen to be simple because of the fact that IE is embedable. So it take a long time to open a new tab, so what. A new skin to match the next OS release was already written, as luck would have it it han't been made public yet. Some of the CSS bugs are a tiny tweak to the source, but passing ACID2
The result IE7, the marketing department is happy, the CSS tweaks mean you can make a page that's crap in IE6 but okay in IE7 and a standard browser, so the spinners are happy. Everyone's happy, well everyone we listen to anyway.