When Gnome tries to make justifiable usability changes, they complain.
People get used to the way the user interface works. If at some later point the behavioure is changed, people will get confused. Making it configurable is a good idea, which is one of the reasons I personally like KDE. KDE can be configured in so many ways, but they could work a bit on making the configuration options easier to find. If you are really sure you can change the user interface for the better, then the confusion may be acceptable, but don't change it too often.
It is used for compression and decompression. Those are tasks that typically takes loads of CPU time. If CPU time was never an issue, we could achieve much better compression ratios. Payloads where the bottleneck is the CPU time used for compression are not rare. And slowing down zlib would certainly make that worse.
But an interesting point however is that typically compression is a lot slower than decompression. Most the security problems are however found in the decompression code. There is a good reason for this. For compression any content on your input stream, so it is clearly impossible to make an attack based on invalid input. For decompression there may exist a few possibilities for invalid compressed input (but not many as those would clearly lead to a poor compression ratio). And even worse, people rarely test decompression of invalid input streams. Valid input streams OTOH are decompressed all the time.
This leads to the question could we sacrifice a bit of performance in the decompression code for better security? And could we do so without hurting compression performance?
It's an ISO-standardAlready? That's great. Do you happen to know the name of that ISO-standard? A reference would be a good thing to have once I have to tell people about this.
Would it be practical to have a summetric cipher with 4094 bit encryption, or would that make things run a bit slow?
256 bit AES use 14 rounds with a 128 bit key in each round. Rather than generating the 1792 bit keyschedule from the 256 bit key, you could just use a 1792 bit key. The speed would be the same as 256 bit AES. But don't expect it to be much more secure.
Most likely the cipher isn't the weakest point anyway. If you want to have 256 bits of entropy in your password you need aproximately 42 random characters.
the pixels may not be warped, but they are still huge and somewhat blurry
If the pixels look blurry it probably means the hardware is still interpolating even though the ratio is an integer. My laptop does the same when trying show a 512x384 pixels image on the 1024x768 pixels screen. Why do they do this? It would have looked so much better if every pixel had just been scaled to twice the size (in both directions).
The suggestion was to use both, which I agree is a good idea, because you get the best from both worlds. Flash have a problem with being overwritten many times, which the suggested design solves by only using it in case of loss of power. Battery backed RAM have a problem with potential data loss if it needs to keep the data for longer time than there is power, which the suggested design solves by writing data to flash as soon as main power is lost. I hope what Samsung will also take care of those problems.
Funny how exploits that are "just theoretical" don't stay that way forever...
I always liked this phrack article about how to exploit an appearently unexploitable bug. After reading this, I would be very cautious about clasifying a bug as unexploitable.
because the monitor is not synchronized with the mouse
I think this is the most important point in your comment. If the mouse polling was synchronized with the monitor you'd get a better result than by polling at 500Hz, and you'd use less CPU power as well. This is one of the cases where the Amiga hardware was superior to the PC, and still is. I mean about 20 years ago the Amiga got timing of input, video and sound exactly right. How come the PC still doesn't do this right?
upgrade to a 2.6 kernel and benefit from the better software RAID...
Is software RAID in 2.6 better than in 2.4? I mean it really works great on my 2.4 based system, in which ways could it become significantly better? First of all performance is really good, a friend of mine spend more money on his RAID controller than I did on my entire computer, still my Linux software RAID runs circles around his hardware RAID. And management of Linux software RAID is actually quite easy.
I heard that in Linux 2.6 you can partition a software RAID, ok that is a nice thing, but building a RAID from harddisk partitions is at least as flexible. The only improvement I really miss is that in case of bad sectors it would sync a spare before kicking out the faulty disk.
Better yet - remove 5 lines. remove 20 lines. remove half the lines... and it better still work!
No, they'd just remove the comments. Rather require them to rewrite such that the source have the same size, but the comments to code ratio have been doubled. And of course it must still work.
all it takes is one developer who isn't interested in closing the sources.
True. Looking on archived versions of the sourceforge pages, it looks like there were once three developers. Few enough that they might have agreed on closing the sources. But still enough for a disagreement leading to publicing full sources.
Interesting story. I started searching for more information on google and archive. And what I found made me start wondering if the source was ever available. Some.tgz files were made available for download from sourceforge, and you can in fact still download them. They do however not contain any source code, just a jar file full of class files. It looks like there was never any possibility to download a tarball with the source code. If the source was ever available, that was only through CVS. And the CVS repository have been wiped pretty thoroughly, even the history of what has happened in the repository is gone. So what was in this CVS repository? Did it contain source code or only jar files? If the source was available I find it strange, that nobody kept a copy. I have not found any evidence the source was ever really available to the public.
Shouldn't you be able to obtain sources to that binary according to the GPL?
Not necesarilly. If binary and sources are made available for download in the same place, it is your own responsibility to remember to download both. If you download only the binary and only too late realize, that you wanted the source as well, it is though luck. Besides even if someone did not provide the source as required only the authors of the binary code being distributed can sue him about it.
As long as the project has only a single author, he can basically do what he wants. (The same applies if all the authors agree).
Actually not. TTL for packets is implemented in IP, which is the layer under TCP. It would defeat the purpose of the TTL if it only existed in TCP packets and all other IP packets could loop. Besides, the routers that decrement TTL are not required to implement TCP, though I think most routers do as they use it for configuration and routing protocols.
That are all good arguments why running as root is a bad choice. But I'd like to add, that I actually backup/home from my cron.daily. So even if somebody could take over my user account and damage my data, they still wouldn't have permission to damage the backups. My next step will be to upload the backups to a friends computer, where a sgid program will ensure I cannot damage a backup once it has been uploaded. When I get that working a backup will be safe even from root.
The beautiful thing is that there were NFS mounted disks on there... He lost a lot, much of it not even his.
There are a few thingss in this story that sounds strange. In a normal configuration doing an rm -rf/home as root on an NFS client will not do much harm, because the squash root feature will mean the server really see you as nobody. Are you saying the server had squash root disabled, or he did this on the server? In either case I'd say that demonstrates somebody has been pretty incompetent. The other thing I wonder about is if there really still are systems where root have / as his homedir? On the systems I use root will use/root as homedir, in which case the command you gave would be almost harmless.
Remember that the base fonts for a platform are provided by the OS vendor, commercial app vendors don't want to deal with this stuff.
This just means the font and application are not linked, and thus the application is not subject to the font license. Even those (sometimes very weird) attempts of calling it a derivated work doesn't apply. The application does not have to be used with any specific font. The application just talks X11, and the X server provides the fonts (which it may get from a font server). In fact the X server can be on a different machine with no GPL software at all.
It took 63 seconds from I pressed the power button on my NCD until I had google opened in mozilla (don't have firefox installed). Of this the first 14 seconds was spent in memory testing, I guess I could speed it up by removing half the RAM. Another 10 was spent starting KDE, so maybe I should install XFce. Now I just need to figure out how to get it running Windows, so I can compare.
Some day I asked myself, what other search engines are there besides google? Well, maybe I should try searching for some. But which search terms are the right ones to use? Actually Google Labs have a service, which is good for this purpose. Go to labs.google.com/sets and put in the name of one or more well known search engines. I got a long list of candidates. Some of the names sounds familiar, others I had not heard about before, but I guess google can also help me find them.
I have seen BitTornado try to download pieces in order skiping those few pieces that were not currently available at any peer. I know that is not how the protocol is supposed to work, but that is how BitTornado behaved. And BTW, I do leave my client uploading for as long time as possible after it have finished downloading.
Slashdot Mirror
When Gnome tries to make justifiable usability changes, they complain.
People get used to the way the user interface works. If at some later point the behavioure is changed, people will get confused. Making it configurable is a good idea, which is one of the reasons I personally like KDE. KDE can be configured in so many ways, but they could work a bit on making the configuration options easier to find. If you are really sure you can change the user interface for the better, then the confusion may be acceptable, but don't change it too often.
I just need to remember which task button represents the window to get to it.
If you use KDE that won't be a problem since all windows have different title line.
If some package/whatever creates an account and I don't know, it can't be exploited.
How could it possibly be exploited? As long as the password field is * or !! and there is no authorized_keys file, then you can't login using ssh.
Is speed really so critical in zlib?
Yes.
It is used for compression and decompression. Those are tasks that typically takes loads of CPU time. If CPU time was never an issue, we could achieve much better compression ratios. Payloads where the bottleneck is the CPU time used for compression are not rare. And slowing down zlib would certainly make that worse.
But an interesting point however is that typically compression is a lot slower than decompression. Most the security problems are however found in the decompression code. There is a good reason for this. For compression any content on your input stream, so it is clearly impossible to make an attack based on invalid input. For decompression there may exist a few possibilities for invalid compressed input (but not many as those would clearly lead to a poor compression ratio). And even worse, people rarely test decompression of invalid input streams. Valid input streams OTOH are decompressed all the time.
This leads to the question could we sacrifice a bit of performance in the decompression code for better security? And could we do so without hurting compression performance?
It's an ISO-standardAlready? That's great. Do you happen to know the name of that ISO-standard? A reference would be a good thing to have once I have to tell people about this.
Would it be practical to have a summetric cipher with 4094 bit encryption, or would that make things run a bit slow?
256 bit AES use 14 rounds with a 128 bit key in each round. Rather than generating the 1792 bit keyschedule from the 256 bit key, you could just use a 1792 bit key. The speed would be the same as 256 bit AES. But don't expect it to be much more secure.
Most likely the cipher isn't the weakest point anyway. If you want to have 256 bits of entropy in your password you need aproximately 42 random characters.
the pixels may not be warped, but they are still huge and somewhat blurry
If the pixels look blurry it probably means the hardware is still interpolating even though the ratio is an integer. My laptop does the same when trying show a 512x384 pixels image on the 1024x768 pixels screen. Why do they do this? It would have looked so much better if every pixel had just been scaled to twice the size (in both directions).
It's not flash (EEPROM), it's battery-backed RAM.
The suggestion was to use both, which I agree is a good idea, because you get the best from both worlds. Flash have a problem with being overwritten many times, which the suggested design solves by only using it in case of loss of power. Battery backed RAM have a problem with potential data loss if it needs to keep the data for longer time than there is power, which the suggested design solves by writing data to flash as soon as main power is lost. I hope what Samsung will also take care of those problems.
Funny how exploits that are "just theoretical" don't stay that way forever...
I always liked this phrack article about how to exploit an appearently unexploitable bug. After reading this, I would be very cautious about clasifying a bug as unexploitable.
because the monitor is not synchronized with the mouse
I think this is the most important point in your comment. If the mouse polling was synchronized with the monitor you'd get a better result than by polling at 500Hz, and you'd use less CPU power as well. This is one of the cases where the Amiga hardware was superior to the PC, and still is. I mean about 20 years ago the Amiga got timing of input, video and sound exactly right. How come the PC still doesn't do this right?
upgrade to a 2.6 kernel and benefit from the better software RAID...
Is software RAID in 2.6 better than in 2.4? I mean it really works great on my 2.4 based system, in which ways could it become significantly better? First of all performance is really good, a friend of mine spend more money on his RAID controller than I did on my entire computer, still my Linux software RAID runs circles around his hardware RAID. And management of Linux software RAID is actually quite easy.
I heard that in Linux 2.6 you can partition a software RAID, ok that is a nice thing, but building a RAID from harddisk partitions is at least as flexible. The only improvement I really miss is that in case of bad sectors it would sync a spare before kicking out the faulty disk.
Don't forget about students who use assert()'s for validating user input!
It is not the best way to validate user input, but it is better than no validation.
Better yet - remove 5 lines. remove 20 lines. remove half the lines ... and it better still work!
No, they'd just remove the comments. Rather require them to rewrite such that the source have the same size, but the comments to code ratio have been doubled. And of course it must still work.
all it takes is one developer who isn't interested in closing the sources.
True. Looking on archived versions of the sourceforge pages, it looks like there were once three developers. Few enough that they might have agreed on closing the sources. But still enough for a disagreement leading to publicing full sources.
Interesting story. I started searching for more information on google and archive. And what I found made me start wondering if the source was ever available. Some .tgz files were made available for download from sourceforge, and you can in fact still download them. They do however not contain any source code, just a jar file full of class files. It looks like there was never any possibility to download a tarball with the source code. If the source was ever available, that was only through CVS. And the CVS repository have been wiped pretty thoroughly, even the history of what has happened in the repository is gone. So what was in this CVS repository? Did it contain source code or only jar files? If the source was available I find it strange, that nobody kept a copy. I have not found any evidence the source was ever really available to the public.
Shouldn't you be able to obtain sources to that binary according to the GPL?
Not necesarilly. If binary and sources are made available for download in the same place, it is your own responsibility to remember to download both. If you download only the binary and only too late realize, that you wanted the source as well, it is though luck. Besides even if someone did not provide the source as required only the authors of the binary code being distributed can sue him about it.
As long as the project has only a single author, he can basically do what he wants. (The same applies if all the authors agree).
Actually that's for TCP's time to live.
Actually not. TTL for packets is implemented in IP, which is the layer under TCP. It would defeat the purpose of the TTL if it only existed in TCP packets and all other IP packets could loop. Besides, the routers that decrement TTL are not required to implement TCP, though I think most routers do as they use it for configuration and routing protocols.
That are all good arguments why running as root is a bad choice. But I'd like to add, that I actually backup /home from my cron.daily. So even if somebody could take over my user account and damage my data, they still wouldn't have permission to damage the backups. My next step will be to upload the backups to a friends computer, where a sgid program will ensure I cannot damage a backup once it has been uploaded. When I get that working a backup will be safe even from root.
The beautiful thing is that there were NFS mounted disks on there... He lost a lot, much of it not even his.
/home as root on an NFS client will not do much harm, because the squash root feature will mean the server really see you as nobody. Are you saying the server had squash root disabled, or he did this on the server? In either case I'd say that demonstrates somebody has been pretty incompetent. The other thing I wonder about is if there really still are systems where root have / as his homedir? On the systems I use root will use /root as homedir, in which case the command you gave would be almost harmless.
There are a few thingss in this story that sounds strange. In a normal configuration doing an rm -rf
Remember that the base fonts for a platform are provided by the OS vendor, commercial app vendors don't want to deal with this stuff.
This just means the font and application are not linked, and thus the application is not subject to the font license. Even those (sometimes very weird) attempts of calling it a derivated work doesn't apply. The application does not have to be used with any specific font. The application just talks X11, and the X server provides the fonts (which it may get from a font server). In fact the X server can be on a different machine with no GPL software at all.
More ISPs should handle compromised computers this way. Just leaving them around to harm the internet for the rest of is is irresponsible.
It took 63 seconds from I pressed the power button on my NCD until I had google opened in mozilla (don't have firefox installed). Of this the first 14 seconds was spent in memory testing, I guess I could speed it up by removing half the RAM. Another 10 was spent starting KDE, so maybe I should install XFce. Now I just need to figure out how to get it running Windows, so I can compare.
Some day I asked myself, what other search engines are there besides google? Well, maybe I should try searching for some. But which search terms are the right ones to use? Actually Google Labs have a service, which is good for this purpose. Go to labs.google.com/sets and put in the name of one or more well known search engines. I got a long list of candidates. Some of the names sounds familiar, others I had not heard about before, but I guess google can also help me find them.
I have seen BitTornado try to download pieces in order skiping those few pieces that were not currently available at any peer. I know that is not how the protocol is supposed to work, but that is how BitTornado behaved. And BTW, I do leave my client uploading for as long time as possible after it have finished downloading.
I hope you never use any code which you didn't write yourself.
Even that is no guarantee the code is legal. Somebody may have patented your algorithm.