U have debian on a LAPTOP?!?!?!?! Do u like whips and chains as well?:)
Yes and yes.
The laptop only has 8Mbytes of meory and has this pathetically slow 50Mhz 486DX2 CPU. Took 16 plus hours to load debian on it, but it loaded. It swapped like mad the hole time, but now I have a portable I can download pictures to while away on trips. Did I load X on it, no, I'm not masochistic.
The Debian installer is already plenty user friendly, just not beginner friendly. Quite a difference if you ask me (and sometimes even opposites!)
This may be waayyyyyy out of leftfield, but isn't someone installing something by definition a beginner?
Not always. I'd been using and administering UNIX for a decade before I first installed Slackware Linux. A few years latter when I changed to Debian I sure wasn't a beginner Linux or UNIX.
Now I will agree that Debian needs a more user friendly installation process. I for one would like to see a better breakdown of the packages into the functionality they provide. I haven't figured out the best way to do it, but it could be provided without much change to the current dselect system. It would mainly take a different classification hierarchy. Alot more fine grained than they have right now. I'd like to be able to go find a listing of "terminal programs" and select from that list, then go on to "browsers", etc.. I don't know of any Linux of *BSD distribution that provides that level of selection yet. Integrating sugestions as to complimentary packages would also be nice. That part would likely take a bit more work than just reclassification.
Use a random number generator that only uses a seed number. Use it to generate numbers that are used for how many steps the rotate the character around the wheel. The four secrets that need to be protected are the random number generator algorithm, seed number, character set sequence, and calculator make and model.
Can it be broken, yes. Coose the random number generator carefully exploiting artifacts unique to the calculator's internal calculation methods and it can easily get quite dificult to crack.
40,000,000 million households, 500,000 units. I guess you get 1/80th of a unit.;)
On the other hand at $100 each, that's peanuts to buy. My guess is the unit will actually be made in million pluss quantities as it would also be quite usefull as a standard PDA/Cell Phone/GPS. I'd buy one, especially if it had a large non-volitile memory for programs and data.
Yep. All the functions they want are available now in one form or another in handhelds. In 6 years they should have them at much reduced cost. I can even see less than $100 in 500k quantities. As I see the way chips are going now. It would fit on two chips plus some support. The main CPU, memory, display and IO control will all fit on one chip by then. The GPS and cell phone part will be another chip. They may even get them merged by then, but I fell the analog side of the cell phone and GPS will likely make it so they still use two chips. The support circutry will be stuff like power supply and IO protection devices, that's it. It will likely be the size of a standard V series palm pilot or maybe even thinner. By then the back of the case will able to be the battery. Got to love the Li-Polymer batteries. Something like that might even get me to carry a cell phone.
As a side note, they really need to ahve them by mid 2008ish. That's only 6 years off.
Even the highest energy density capacitors are easily out stripped by the lowest energy density batteries. Granted thay have made huge strides in the past years with the Ultra capacitors and at some point break even with batteries. You can now get multiple Farad capacitors but that is still peanuts in comparison to an AA battery. On the other hand research may at some point allow them to catch up or surpass batteries.
This shows you don't understand the current standard UNIX mail distribution programs. All that I've worked with can be configured to strip headers. No need to program your own mail transport. Most of the list server software is the same way. It is a bad idea to strip the headers or change the message ID. If you do either or both you can break the ability of many automatic loop detection systems to do their job.
I run a few lists and every once in awhile I get a looped message, but you know, it usually only spins about once and never finished the second circuit before being chopped off and dropped into the hands of the postmaster.
The F-15 was the first. I think the F-16 is also in that class. I stopped following jet figheters so I don't know what the F-18 and latter ones have.
On another note the cars mentioned aren't all that technologically advanced. Maby for an American production car, but not for cars in general. Just because a car company says so dosen't mean it is so.
Please do a bit of independent verification. Don't just be a passive consumer, actively seek out information and verify facts.
This unique user ID can be attacked. The same reasonings behind not allowing disclosure of video and book loands can also be used to squelch this unique listener ID number.
On a side note:
Sombody needs to write an app that randomizes the content of these cookies that are being sent to M$. At boot and periodically there after it goes, finds and randomizes all the cookie values. Every 15 minutes would be a good time cycle. If it could hook it's self into app launch it wouldn't need to change what is on the disk. The paterns to look for in memory can be located on disk from the configuration files of the apps.
Look for all the methods one might possibly use to make the collected data worthless, or attack the collection of the data. It is your duty to yell and complain when companies cross your comfort threshold.
This logging and reporting can be attacked. The same reasonings behind the law that protects one from having one's book and video lending records from being exposed can be used to attack these logging requirements.
Considering they were starting from SGI that wouldn't help much. On the other hand a relatively generic X --> Y CPU code rewriter and optimizer would be a good project. On top of that one can then have modules that support various different hardware/OS environments. MIPS/IRIX could be one of many.
Wearables Central is a good place to start. People lookinto wearable computers have been looking for hardware that is both small and low powered. Plus many of them have been interested in sound. Something about needing it for speach recognition and sound output. You don't have a much space constraints so you could go with a dedicated sound board. I'd look into PC-104 based single board computes then add a sound board. For the screen, choose one from those supported by the SBC. For harddisk I'd use two laptop drives used in mirrored mode. That way if one fails, the other can take up the task. Case wise I'd get one of the standard PC-104 extruded AL cases, and add rubber bumpers. Power can come from a wall brick. Check out DigiKey. Personally I'd expect one of them DVD-RAM drives to die from vibration long before a good laptop HD would.
Those temps are much higher than what you'd be cooking a pizza at.
Actually, no they aren't. Proper pizza cooking should be done at about the same temps. Those frozen ready made pizzas all cook at low temps. I grew up cooking pizza in an oven set at 550F. I don't remember the exact temperatures used in reflow, but I had calculated that a convection oven that reaches 500F would do fine. 250C seames to pop up as a likely maximum temperature.
Hard drives may be more reliable than tapes, but when the server room has water spewing from the AC and your controllers short out, guess what?
Your "backups" are toast.
Floods, tornadoes, fires, etc happen. Sometimes people fly planes into buildings. When that happens, tapes are the only thing that keeps your business in business.
No, actually it is off site backups that save your ass. All the tapes in the world won't save your ass unless you have carried backup sets off site.
Off Site Backups can be done with harddisks too. The main advantage of tapes it they are usually less fragile than hard disks, but the costs of the tapes for some large capacity tape backup systems are higher per MB than the multi GB consumer IDE disks and they don't provide random access.
An idea I had for backups was to have a system be a mirror for the main disks. As the day went on it would mirror all the changes to the main file server. At 6PM or so (end of busisness day plus an hour) the current DB after image file would be copied to the mirror and mirror would be broken, the disks pulled, and a set from the week before installed. The mirror would then be restarted bringing the old backups up to date. The removed set would then go home as the current offsite backup. Tape and DB backups would happen as normal. The DB backup would be written to a partition on the disk set. I would think this become infeasable if one has to backup more than 4 to 8 disks worth. At this point that could be more than one TB. There would be a set of disks for each day of the week. Weekly tape backups would be the long term archive, while the disk sets would be the offsite backup.
Look and find the real bottleneck. Check which queries are being done all the time. Are there indexes for them?
I've run into querey nightmares quite often. One DB I helped tune kindof had an index the DB could use to narrow down the search, but it still left over a thousand records to search through to find the needed one. They we calling this query a few times a minute durring busisness hours. A simple index addition and they went from 100% saturation on the disk IO system to less than 1%. Sounds extreme, but it isn't. Bad indexing can be a real killer. So can poor selection criteria in a query. Both were at fault in this case, it is just that the DB query optimizers could deal with the poor selection criteria once it had a better fitting index. Bad indexing and queries cause the DB to need to build temporary indexes whice usually only can be used for those specific query run instance. This takes disk IO, memory, and CPU time that can be better spent elsewhere. It also makes for much duplicated effort.
Another optimization fuckup. One place decided what they needed was more RAM. Users weren't getting their queries back fast enough, and the network wasn't saturated. It turned out that they already had over three times more RAM than the total size of their DB. Net effect, one happy hardware salesman and no DB speed up. They had a CPU bottleneck. Going to an eight way system and distributing the RAM they had to the six new CPUS changed their problem over to one of network access speed. Adding three more 100Mbit NICs solved the new problem and gave them some breathing room. Disk IO still wasn't and issue, though write speed was looking like it would be the next bottleneck. They went from about 12% of max write throughput to close to 65% durring only a few nightly batch jobs. Even then it would only be an issue if they weren't done by morning. The rest of the time they spent near.1% disk utilization. Reads, what reads. After the hole DB got cached into RAM the system only wrote to the disks. Consider that when you are evaluating benchmarks.
Most databases I see hare horrors when it comes to indexing and physical database layout. These are the ones put together by profesionals. The ones put together by amatures make the profesionals look like saints. If you put the before image, after image and data files on the same disk subsystem they all fight for IO time, and you loose speed. You'll be about half as fast. The before image and after image files can overlap their writes, but the data file can't have writes done to it until the before image data is written to disk. The after image data has to wait till the data segment writes have completed. Splitting them out onto their own disks allows for a significant increase in speed. The before image writes for one query can now overlap the data writes of the previously processed query. The after image writes can also be overlapped. Also get additional disk subsystems each for your log files and index files. Spread the IO out. This also provides better data integrity. If your data segment's disk subsystem quits, you can rebuild the DB up to the last commit from a backup and the after image file.
I forgot to divide by 8! Change of plan: Wait for the 10 gigabit NICs to be released to the public. I guess I could place it on the 64-bit 33 Mhz bus.
For a 10 gigabit NIC you would need a much faster local bus. Better at that point to change out the underlying motherboard and processors while your at it. People just don't understand numbers and their importance.
This guy needs to really figure out where his true bottleneck is before changing things. Looking at the setup. The two optimizations I see are gigabit NIC or multiple 100Mbit NICs and switching to RAID 0+1. That's it. Without reallying looking at actual performance numbers and profiling I wouldn't touch it.
Performance tuning for the sake of performance tuning is just asking for trouble. Do it when you know you need the extra performance or know you will need it soon. My bet he could get all his DB/Disk speedup via tuning the DB. He could get the communication speedup by going with a 64bit/66Mhz gigabit NIC for talking to the users.
From the sounds of the system layout it looks like the original DB wasn't setup properly. Only the data segments of the DB should be on RAID 5 and then only if you don't have the hardware to go RAID 0+1. The rest should be on RAID 0+1 or just stripped. I also bet there aren't separate RAIDs for data, index, before and after image, and log files. Separate off the before image, after image, and log files first, then separate out the indexes, each to their own RAID. The indexes should just be on the fastest RAID 0+1 array you can afford. The before and after image RAIDs should be in the same speed class as the main data RAID. The striping on them should be short as they are only accessed sequentially. The data and index segments need fast seek and low latency to perform best.
First thing is find out where the real bottleneck is. Don't just swap and hope you solve it. You don't want to swap something out to find out the replacement isn't stable.
(if the frequency of one generator would be different an enormous current would flow from the other plants into this generator and it would most probably blow up).
A small power company where I useto live accidentally connected up a generator out of phase. They retreived the alternator core from the basement of a building over a half mile away. Thankfully no one was hurt. That was only a 1 Mega Watt generator. It weighed a few tons. Before it had left the power plant it had sheared off a 10 inch drive shaft and cracked the case on a huge diesel engine. The remains of the strator housing destroyed the generators on both side of it.
The electricity may have had to be produced somewhere, but even the dirtiest of power plants is much much cleaner and more efficient burner of fossile fules than the cleanest of regular automobile engines. Do your homework and actually gather the figures instead of replaying the kneejerk reactions of others.
As for the lead acid batteries, almost all are recycled now. The few that aren't are because of idiots who don't realise that they can be exchanged for $$$ at the recycler. The recyclers want that lead, plastic, and acid back as all can be recycled. The only part of a lead acid battery that isn't recycled is the label.
Yes, storing by directory just dosen't work. I have over 17G of photos taken by my digital camera. Each photo gets linked into multiple directories. One tree is date/time based and the other is subject based. I automatically build HTML index files for each directory. Even then it can still be hard to locate the photograph I want. The problem is the description of what is in the photograh. There isn't a decent way to automatically extract that information from a photograph. It must be done by hand. Often the photograph is so old nobody remembers what the subject is. Shure it is a person, but who is it? Where was it taken even? I try to keep meta data files for each photograph, but one dosen't always have the time to properly enter the data.
If it were possible to impose some small fine on every system involved (or worse yet, if the suystem's ISP were fined, encouraging them to shut down offending systems), then people would start to take notice. Hopefully, people would start to realize that it is everyone's responsibility to maintain safe systems.
One also needs to go after the software venders that ship insecure systems. Security is not a single step, it is a process that needs to be applied at all levels and continiously. Untill M$ and all the other venders really implement security in their products, the user of those products can only secure them so much. When you have a program automatically execute untrusted code, what can you do? Not much. Your screwed.
Slashdot Mirror
Yes and yes.
The laptop only has 8Mbytes of meory and has this pathetically slow 50Mhz 486DX2 CPU. Took 16 plus hours to load debian on it, but it loaded. It swapped like mad the hole time, but now I have a portable I can download pictures to while away on trips. Did I load X on it, no, I'm not masochistic.
This may be waayyyyyy out of leftfield, but isn't someone installing something by definition a beginner?
Not always. I'd been using and administering UNIX for a decade before I first installed Slackware Linux. A few years latter when I changed to Debian I sure wasn't a beginner Linux or UNIX.
Now I will agree that Debian needs a more user friendly installation process. I for one would like to see a better breakdown of the packages into the functionality they provide. I haven't figured out the best way to do it, but it could be provided without much change to the current dselect system. It would mainly take a different classification hierarchy. Alot more fine grained than they have right now. I'd like to be able to go find a listing of "terminal programs" and select from that list, then go on to "browsers", etc.. I don't know of any Linux of *BSD distribution that provides that level of selection yet. Integrating sugestions as to complimentary packages would also be nice. That part would likely take a bit more work than just reclassification.
Can it be broken, yes. Coose the random number generator carefully exploiting artifacts unique to the calculator's internal calculation methods and it can easily get quite dificult to crack.
On the other hand at $100 each, that's peanuts to buy. My guess is the unit will actually be made in million pluss quantities as it would also be quite usefull as a standard PDA/Cell Phone/GPS. I'd buy one, especially if it had a large non-volitile memory for programs and data.
As a side note, they really need to ahve them by mid 2008ish. That's only 6 years off.
Even the highest energy density capacitors are easily out stripped by the lowest energy density batteries. Granted thay have made huge strides in the past years with the Ultra capacitors and at some point break even with batteries. You can now get multiple Farad capacitors but that is still peanuts in comparison to an AA battery. On the other hand research may at some point allow them to catch up or surpass batteries.
I run a few lists and every once in awhile I get a looped message, but you know, it usually only spins about once and never finished the second circuit before being chopped off and dropped into the hands of the postmaster.
The essay forces them to think about what they did wron and why it was wrong... I actually like the idea.
On another note the cars mentioned aren't all that technologically advanced. Maby for an American production car, but not for cars in general. Just because a car company says so dosen't mean it is so.
Please do a bit of independent verification. Don't just be a passive consumer, actively seek out information and verify facts.
This unique user ID can be attacked. The same reasonings behind not allowing disclosure of video and book loands can also be used to squelch this unique listener ID number.
On a side note:
Sombody needs to write an app that randomizes the content of these cookies that are being sent to M$. At boot and periodically there after it goes, finds and randomizes all the cookie values. Every 15 minutes would be a good time cycle. If it could hook it's self into app launch it wouldn't need to change what is on the disk. The paterns to look for in memory can be located on disk from the configuration files of the apps.
Look for all the methods one might possibly use to make the collected data worthless, or attack the collection of the data. It is your duty to yell and complain when companies cross your comfort threshold.
This logging and reporting can be attacked. The same reasonings behind the law that protects one from having one's book and video lending records from being exposed can be used to attack these logging requirements.
Considering they were starting from SGI that wouldn't help much. On the other hand a relatively generic X --> Y CPU code rewriter and optimizer would be a good project. On top of that one can then have modules that support various different hardware/OS environments. MIPS/IRIX could be one of many.
Wearables Central is a good place to start. People lookinto wearable computers have been looking for hardware that is both small and low powered. Plus many of them have been interested in sound. Something about needing it for speach recognition and sound output. You don't have a much space constraints so you could go with a dedicated sound board. I'd look into PC-104 based single board computes then add a sound board. For the screen, choose one from those supported by the SBC. For harddisk I'd use two laptop drives used in mirrored mode. That way if one fails, the other can take up the task. Case wise I'd get one of the standard PC-104 extruded AL cases, and add rubber bumpers. Power can come from a wall brick. Check out DigiKey. Personally I'd expect one of them DVD-RAM drives to die from vibration long before a good laptop HD would.
Actually, no they aren't. Proper pizza cooking should be done at about the same temps. Those frozen ready made pizzas all cook at low temps. I grew up cooking pizza in an oven set at 550F. I don't remember the exact temperatures used in reflow, but I had calculated that a convection oven that reaches 500F would do fine. 250C seames to pop up as a likely maximum temperature.
Considering some of the server rooms I've been in. Colder than ambient equils frozen beer.
Your "backups" are toast.
Floods, tornadoes, fires, etc happen. Sometimes people fly planes into buildings. When that happens, tapes are the only thing that keeps your business in business.
No, actually it is off site backups that save your ass. All the tapes in the world won't save your ass unless you have carried backup sets off site.
Off Site Backups can be done with harddisks too. The main advantage of tapes it they are usually less fragile than hard disks, but the costs of the tapes for some large capacity tape backup systems are higher per MB than the multi GB consumer IDE disks and they don't provide random access.
An idea I had for backups was to have a system be a mirror for the main disks. As the day went on it would mirror all the changes to the main file server. At 6PM or so (end of busisness day plus an hour) the current DB after image file would be copied to the mirror and mirror would be broken, the disks pulled, and a set from the week before installed. The mirror would then be restarted bringing the old backups up to date. The removed set would then go home as the current offsite backup. Tape and DB backups would happen as normal. The DB backup would be written to a partition on the disk set. I would think this become infeasable if one has to backup more than 4 to 8 disks worth. At this point that could be more than one TB. There would be a set of disks for each day of the week. Weekly tape backups would be the long term archive, while the disk sets would be the offsite backup.
Yep.
Look and find the real bottleneck. Check which queries are being done all the time. Are there indexes for them?
I've run into querey nightmares quite often. One DB I helped tune kindof had an index the DB could use to narrow down the search, but it still left over a thousand records to search through to find the needed one. They we calling this query a few times a minute durring busisness hours. A simple index addition and they went from 100% saturation on the disk IO system to less than 1%. Sounds extreme, but it isn't. Bad indexing can be a real killer. So can poor selection criteria in a query. Both were at fault in this case, it is just that the DB query optimizers could deal with the poor selection criteria once it had a better fitting index. Bad indexing and queries cause the DB to need to build temporary indexes whice usually only can be used for those specific query run instance. This takes disk IO, memory, and CPU time that can be better spent elsewhere. It also makes for much duplicated effort.
Another optimization fuckup. One place decided what they needed was more RAM. Users weren't getting their queries back fast enough, and the network wasn't saturated. It turned out that they already had over three times more RAM than the total size of their DB. Net effect, one happy hardware salesman and no DB speed up. They had a CPU bottleneck. Going to an eight way system and distributing the RAM they had to the six new CPUS changed their problem over to one of network access speed. Adding three more 100Mbit NICs solved the new problem and gave them some breathing room. Disk IO still wasn't and issue, though write speed was looking like it would be the next bottleneck. They went from about 12% of max write throughput to close to 65% durring only a few nightly batch jobs. Even then it would only be an issue if they weren't done by morning. The rest of the time they spent near .1% disk utilization. Reads, what reads. After the hole DB got cached into RAM the system only wrote to the disks. Consider that when you are evaluating benchmarks.
Most databases I see hare horrors when it comes to indexing and physical database layout. These are the ones put together by profesionals. The ones put together by amatures make the profesionals look like saints. If you put the before image, after image and data files on the same disk subsystem they all fight for IO time, and you loose speed. You'll be about half as fast. The before image and after image files can overlap their writes, but the data file can't have writes done to it until the before image data is written to disk. The after image data has to wait till the data segment writes have completed. Splitting them out onto their own disks allows for a significant increase in speed. The before image writes for one query can now overlap the data writes of the previously processed query. The after image writes can also be overlapped. Also get additional disk subsystems each for your log files and index files. Spread the IO out. This also provides better data integrity. If your data segment's disk subsystem quits, you can rebuild the DB up to the last commit from a backup and the after image file.
For a 10 gigabit NIC you would need a much faster local bus. Better at that point to change out the underlying motherboard and processors while your at it. People just don't understand numbers and their importance.
This guy needs to really figure out where his true bottleneck is before changing things. Looking at the setup. The two optimizations I see are gigabit NIC or multiple 100Mbit NICs and switching to RAID 0+1. That's it. Without reallying looking at actual performance numbers and profiling I wouldn't touch it.
Performance tuning for the sake of performance tuning is just asking for trouble. Do it when you know you need the extra performance or know you will need it soon. My bet he could get all his DB/Disk speedup via tuning the DB. He could get the communication speedup by going with a 64bit/66Mhz gigabit NIC for talking to the users.
From the sounds of the system layout it looks like the original DB wasn't setup properly. Only the data segments of the DB should be on RAID 5 and then only if you don't have the hardware to go RAID 0+1. The rest should be on RAID 0+1 or just stripped. I also bet there aren't separate RAIDs for data, index, before and after image, and log files. Separate off the before image, after image, and log files first, then separate out the indexes, each to their own RAID. The indexes should just be on the fastest RAID 0+1 array you can afford. The before and after image RAIDs should be in the same speed class as the main data RAID. The striping on them should be short as they are only accessed sequentially. The data and index segments need fast seek and low latency to perform best.
First thing is find out where the real bottleneck is. Don't just swap and hope you solve it. You don't want to swap something out to find out the replacement isn't stable.
A small power company where I useto live accidentally connected up a generator out of phase. They retreived the alternator core from the basement of a building over a half mile away. Thankfully no one was hurt. That was only a 1 Mega Watt generator. It weighed a few tons. Before it had left the power plant it had sheared off a 10 inch drive shaft and cracked the case on a huge diesel engine. The remains of the strator housing destroyed the generators on both side of it.
Damn you slashdot! :)
I know the feeling. I currently have to many half finished projects on the plate.
Um, try 70's.
As for the lead acid batteries, almost all are recycled now. The few that aren't are because of idiots who don't realise that they can be exchanged for $$$ at the recycler. The recyclers want that lead, plastic, and acid back as all can be recycled. The only part of a lead acid battery that isn't recycled is the label.
Yes, storing by directory just dosen't work. I have over 17G of photos taken by my digital camera. Each photo gets linked into multiple directories. One tree is date/time based and the other is subject based. I automatically build HTML index files for each directory. Even then it can still be hard to locate the photograph I want. The problem is the description of what is in the photograh. There isn't a decent way to automatically extract that information from a photograph. It must be done by hand. Often the photograph is so old nobody remembers what the subject is. Shure it is a person, but who is it? Where was it taken even? I try to keep meta data files for each photograph, but one dosen't always have the time to properly enter the data.
One also needs to go after the software venders that ship insecure systems. Security is not a single step, it is a process that needs to be applied at all levels and continiously. Untill M$ and all the other venders really implement security in their products, the user of those products can only secure them so much. When you have a program automatically execute untrusted code, what can you do? Not much. Your screwed.
Er, no. Malformed packets kill only badly written, insecure servers.
Even well formed packets can kill a server. To many of them can run a server out of resources.