After the recently-implemented algorithmic complexity attack against many hash table implementations (story on Slashdot a couple of months ago), many more programmers have reason to be concerned about the worst case. If you are hashing inputs taken directly (or perhaps even indirectly) from the user, then by choosing the right strings an attacker can DoS your system by making lots of hash collisions, so each lookup becomes effectively a linear search.
I don't know what Python (or other scripting languages) are doing to address this; many on the Python newsgroup seemed not to care and said that the operating system should deal with any process which is using too much CPU time, but I don't know if this attitude is shared by the real Python developers.
Perhaps for security-conscious applications you could choose to use red-black trees or some other implementation of associative arrays, at least in cases where strings sent by the user are used as part of a hash key. Perhaps Perl's tainting mechanism could help with this.
The assassination of the King of Jordan sounds dramatic, but more mundane political changes have been bet on for a long time now. And in some cases in an ideas market system between individuals, not just solely with a traditional bookmaker. I know that Sporting Index and Betfair (the latter site seems to be rather IE-specific) have bets on the outcome of elections. A typical instrument might be one that pays $1 for every seat won by a political party in one parliamentary election - so if the party wins 200 seats you receive $200. Then the price this instrument trades at tells you the market's expectation of the result; a market-maker like Sporting Index might offer to buy the instrument at $300 and sell at $330. For Betfair, I think the price is solely determined by individuals.
As for whether anyone would want to place such bets, I can imagine that if you were the King's wife or close associate you might want to hedge against him being killed; in fact betting that he will be assassinated is just another form of life insurance. Or if you are the king's son and can't wait to succeed to the throne, bet that he won't be assassinated in the next 20 years, and on that future security borrow some money to fund your playboy lifestyle in the meantime.
It looks like the problem is increasingly one of messages that are not spam, but get blocked by filters or by trigger-happy pressing of the 'D' key. Since no filter and no human can ever be entirely accurate at detecting what is spam given only a few seconds to look at each message, and the spam being sent is evolving to look more like genuine messages at a quick glance, this problem will only get worse.
What's needed is some way to mark messages as 'definitely not spam' so that filters can ignore them. Some have used PGP signatures for this in the past, but I'm getting an increasing amount of PGP-signed spam. The trouble is that generating a PGP signature is not costly for the spammer.
However a system like Hash Cash could work, because it costs a few seconds of CPU time per message to mark it, making the system unusable by spammers who need to send hundreds of thousands of messages to break even. A message with the right amount of postage attached could be let through by filters; in the long run it would be better for mail user agents to do the filtering themselves based on a postage rate set by the user, but right now it would have to be done on the server with a fixed postage rate (perhaps equivalent to 5 seconds of CPU time on a current low-end PC).
32 megs sounds like more than enough - if you allocate say 20 megs as picture buffering storage, and run your operating system in the remaining 12 megs to read mail and stuff.
No, Knoppix at least does not read the whole OS into RAM. It couldn't, not with 700 megs of data. You're thinking of installers like Red Hat's which do run from a RAM disk in memory. But it's not feasible to fit KDE and all applications in system RAM, at least not yet.
Still, one would hope that once the system has been up for a while most important things will be cached, so the CD player can have a rest.
It could be rebadged Knoppix, but I think it's more likely they tweaked Lindows to run from CD (since if they started with Knoppix there would be a lot of work to add back all the Lindows crud like Click-N-Run).
Sure, Lindows is a marketing-focused company not a technically-focused company, but they seem to to a good job. _Someone_ has to get out there and set up the deals with hardware manufacturers and distributors, so that consumers can get their $119 PCs.
If you have a digital camera, you don't need a touch screen webpad. You could point the camera at a piece of paper and draw on the paper. This could obviously be used for making drawings, but also, provided the camera can see where the tip of the pencil is (or perhaps just the tip of your finger) it can take that as the mouse pointer position. You could move your thumb in a particular direction to 'click'.
Or, point the camera at a wall and use a laser pointer to make a dot it can follow.
Should be easy to change the OS
on
Lindows Webstation
·
· Score: 4, Interesting
If it works with Lindows, then it should also be possible to stick in a Knoppix CD. In fact, it's surprising that nobody else is marketing cheap PCs using Knoppix or a similar distribution.
What kind of CPU is used in digital cameras like this? Perhaps an ARM or i960 or other embedded processor? How much memory does the camera have for storing pictures?
I'm not talking about the browser, I'm talking about ordinary desktop icons and window decorations. Another poster mentioned that this will be implemented in KDE 3.2. GNOME 2.2 already has an SVG icon renderer.
I think most corporate frauds are because of stealing from the investors, not stealing from other companies or individuals. (This phone charges thing is an exception.) So the executives or a small group of investors steal money from the majority of investors, or from the company (which is owned by the investors). The company goes bankrupt because of the fraud. The guilty parties weren't stealing or lying to keep the company afloat (except in the short term), but to line their own pockets.
Truly 'corporate' dishonesty where a company steals in order to make profits and stay in business, seems rarer than you'd think. This must be because not many people are dishonest enough to commit fraud, yet honest enough to make sure the money goes to the shareholders rather than into their own pockets. Unless, of course, they hope to get paid bonuses for increasing the share price, but even then it's a lot of risk for only a small part of the reward.
Bamboo canes are hollow, right? So just use aluminium rods with bamboo cladding round the outside. You get a strong and stable bike, and still get all the eco-friendly posing opportunities. It's not as if anyone will try to cut the bamboo open to see if you're cheating.
What I mean is that no matter what DPI settings you give to Windows, it still seems to display dialogue boxes at a fixed _pixel_ size.
Anyone can make a box that lets you type in a number of dots per inch - whether the GUI uses that number to adjust the display intelligently is what matters.
Thanks for the tip. But I'm sure that Windows (or Win2k at least) does not adjust dialogue boxes to the screen resolution. When you increase the screen resolution from say 1024x768 to 1600x1200, all the dialogue boxes and icons on the screen get smaller; when you decrease the resolution, everything gets bigger. Messing with Small Fonts / Large Fonts is the only way to compensate.
Hmm - that's not how I remember it from the time. The KDE developers encouraged users to spam the GIMP mailing list (see http://lists.kde.org/?l=kde&m=90221990129738&w=2). As if it were some particular obstructionism by the GIMP developers that prevented their code being linked with Qt. In the end the GIMP developers had to write a message (posted as a story on Slashdot, though I can't find it now) asking the KDE users to please stop spamming the list.
Yes, text in dialogue boxes scales nowadays, but icons still remain a constant size. Perhaps you're right that this is no big deal (you don't really need to see icons clearly, just have a vague visual memory of which is which).
It does suck that Windows doesn't allow any more fine-grained control than Small, Large or Extra Large fonts. You should just be able to tell it the size of your monitor and have fonts displayed at the *correct* size, dammit. By which I mean a ten-point font should display with characters ten points high. I don't know how well GNOME and KDE handle this, but there is a way to tell the X server your real display resolution.
(A point is roughly 1/72 inches, I think. http://www.cl.cam.ac.uk/~mgk25/metric-typo/ makes a good argument for abandoning the whole 'points' mess and simply stating font size in millimetres.)
Rantings by GNOME fanboys shouldn't be confused with real legal difficulties. As far as I can tell there's zero overlap between fanboys and developers. Besides, GIMP isn't really part of GNOME, it just got adopted in some vague way because it uses GTK. As far as I know it still doesn't use the GNOME libraries.
The trouble with the port made three years ago was that it wasn't allowed by the GPL. As you know, you're not allowed to mix GPLed code with non-GPLed code, and at that time Qt was not GPLed. It's nothing about the GIMP developers being particularly awkward; the same applies to any GPLed program. And when the copyright is held by many different people, it's not easy to get all of them together to grant an exception to the licence.
Perhaps you think the GIMP developers were being silly to use the GPL, and they should have used the LGPL instead to allow linking with non-GPLed libraries. But then the KDE developers and thousands of other projects are just the same in this regard. (For example, it would not be legal to port KWord to Motif unless you had explicit permission from all copyright holders. Not that you'd probably want to do this - it's just another example of wanting to port a program to a different widget set, and being stopped by the copying conditions.)
But now that Qt is available under the GPL, it would be legal to distribute KIMP. But the code hasn't reappeared:-(.
The trouble is there are still a lot of apps that specify things in pixel sizes rather than in real units (centimetres) or some other scalable unit (fraction of the total display size). So even if you increase the font size - and that would require a system with fonts that aren't ugly, so you're not forced to use a few predefined bitmaps - you may find everything else is too small.
It'll be great when everything uses SVG icons which are rendered at the size you choose and at the right resolution for the display, but that day is a way off yet.
Slashdot Mirror
Actually the closest linguistic relative of English is Scots (which was once considered the same language, but was rebranded for marketing purposes).
Can someone explain the reference?
After the recently-implemented algorithmic complexity attack against many hash table implementations (story on Slashdot a couple of months ago), many more programmers have reason to be concerned about the worst case. If you are hashing inputs taken directly (or perhaps even indirectly) from the user, then by choosing the right strings an attacker can DoS your system by making lots of hash collisions, so each lookup becomes effectively a linear search.
I don't know what Python (or other scripting languages) are doing to address this; many on the Python newsgroup seemed not to care and said that the operating system should deal with any process which is using too much CPU time, but I don't know if this attitude is shared by the real Python developers.
Perhaps for security-conscious applications you could choose to use red-black trees or some other implementation of associative arrays, at least in cases where strings sent by the user are used as part of a hash key. Perhaps Perl's tainting mechanism could help with this.
The assassination of the King of Jordan sounds dramatic, but more mundane political changes have been bet on for a long time now. And in some cases in an ideas market system between individuals, not just solely with a traditional bookmaker. I know that Sporting Index and Betfair (the latter site seems to be rather IE-specific) have bets on the outcome of elections. A typical instrument might be one that pays $1 for every seat won by a political party in one parliamentary election - so if the party wins 200 seats you receive $200. Then the price this instrument trades at tells you the market's expectation of the result; a market-maker like Sporting Index might offer to buy the instrument at $300 and sell at $330. For Betfair, I think the price is solely determined by individuals.
As for whether anyone would want to place such bets, I can imagine that if you were the King's wife or close associate you might want to hedge against him being killed; in fact betting that he will be assassinated is just another form of life insurance. Or if you are the king's son and can't wait to succeed to the throne, bet that he won't be assassinated in the next 20 years, and on that future security borrow some money to fund your playboy lifestyle in the meantime.
So Mr Mackey's tie-caused head-inflation is accurate?
It looks like the problem is increasingly one of messages that are not spam, but get blocked by filters or by trigger-happy pressing of the 'D' key. Since no filter and no human can ever be entirely accurate at detecting what is spam given only a few seconds to look at each message, and the spam being sent is evolving to look more like genuine messages at a quick glance, this problem will only get worse.
What's needed is some way to mark messages as 'definitely not spam' so that filters can ignore them. Some have used PGP signatures for this in the past, but I'm getting an increasing amount of PGP-signed spam. The trouble is that generating a PGP signature is not costly for the spammer.
However a system like Hash Cash could work, because it costs a few seconds of CPU time per message to mark it, making the system unusable by spammers who need to send hundreds of thousands of messages to break even. A message with the right amount of postage attached could be let through by filters; in the long run it would be better for mail user agents to do the filtering themselves based on a postage rate set by the user, but right now it would have to be done on the server with a fixed postage rate (perhaps equivalent to 5 seconds of CPU time on a current low-end PC).
It's not the editors' fault, it's just that final sentences like the above are inserted automatically by the Slashdot story generator.
32 megs sounds like more than enough - if you allocate say 20 megs as picture buffering storage, and run your operating system in the remaining 12 megs to read mail and stuff.
No, Knoppix at least does not read the whole OS into RAM. It couldn't, not with 700 megs of data. You're thinking of installers like Red Hat's which do run from a RAM disk in memory. But it's not feasible to fit KDE and all applications in system RAM, at least not yet.
Still, one would hope that once the system has been up for a while most important things will be cached, so the CD player can have a rest.
It could be rebadged Knoppix, but I think it's more likely they tweaked Lindows to run from CD (since if they started with Knoppix there would be a lot of work to add back all the Lindows crud like Click-N-Run).
Sure, Lindows is a marketing-focused company not a technically-focused company, but they seem to to a good job. _Someone_ has to get out there and set up the deals with hardware manufacturers and distributors, so that consumers can get their $119 PCs.
If you have a digital camera, you don't need a touch screen webpad. You could point the camera at a piece of paper and draw on the paper. This could obviously be used for making drawings, but also, provided the camera can see where the tip of the pencil is (or perhaps just the tip of your finger) it can take that as the mouse pointer position. You could move your thumb in a particular direction to 'click'.
Or, point the camera at a wall and use a laser pointer to make a dot it can follow.
If it works with Lindows, then it should also be possible to stick in a Knoppix CD. In fact, it's surprising that nobody else is marketing cheap PCs using Knoppix or a similar distribution.
All right, I won't mention the L-word.
What kind of CPU is used in digital cameras like this? Perhaps an ARM or i960 or other embedded processor? How much memory does the camera have for storing pictures?
Does it run Linux?
I'm not talking about the browser, I'm talking about ordinary desktop icons and window decorations. Another poster mentioned that this will be implemented in KDE 3.2. GNOME 2.2 already has an SVG icon renderer.
I think most corporate frauds are because of stealing from the investors, not stealing from other companies or individuals. (This phone charges thing is an exception.) So the executives or a small group of investors steal money from the majority of investors, or from the company (which is owned by the investors). The company goes bankrupt because of the fraud. The guilty parties weren't stealing or lying to keep the company afloat (except in the short term), but to line their own pockets.
Truly 'corporate' dishonesty where a company steals in order to make profits and stay in business, seems rarer than you'd think. This must be because not many people are dishonest enough to commit fraud, yet honest enough to make sure the money goes to the shareholders rather than into their own pockets. Unless, of course, they hope to get paid bonuses for increasing the share price, but even then it's a lot of risk for only a small part of the reward.
Bamboo canes are hollow, right? So just use aluminium rods with bamboo cladding round the outside. You get a strong and stable bike, and still get all the eco-friendly posing opportunities. It's not as if anyone will try to cut the bamboo open to see if you're cheating.
What I mean is that no matter what DPI settings you give to Windows, it still seems to display dialogue boxes at a fixed _pixel_ size.
Anyone can make a box that lets you type in a number of dots per inch - whether the GUI uses that number to adjust the display intelligently is what matters.
Thanks for the tip. But I'm sure that Windows (or Win2k at least) does not adjust dialogue boxes to the screen resolution. When you increase the screen resolution from say 1024x768 to 1600x1200, all the dialogue boxes and icons on the screen get smaller; when you decrease the resolution, everything gets bigger. Messing with Small Fonts / Large Fonts is the only way to compensate.
Hmm - that's not how I remember it from the time. The KDE developers encouraged users to spam the GIMP mailing list (see http://lists.kde.org/?l=kde&m=90221990129738&w=2). As if it were some particular obstructionism by the GIMP developers that prevented their code being linked with Qt. In the end the GIMP developers had to write a message (posted as a story on Slashdot, though I can't find it now) asking the KDE users to please stop spamming the list.
Yes, text in dialogue boxes scales nowadays, but icons still remain a constant size. Perhaps you're right that this is no big deal (you don't really need to see icons clearly, just have a vague visual memory of which is which).
It does suck that Windows doesn't allow any more fine-grained control than Small, Large or Extra Large fonts. You should just be able to tell it the size of your monitor and have fonts displayed at the *correct* size, dammit. By which I mean a ten-point font should display with characters ten points high. I don't know how well GNOME and KDE handle this, but there is a way to tell the X server your real display resolution.
(A point is roughly 1/72 inches, I think. http://www.cl.cam.ac.uk/~mgk25/metric-typo/ makes a good argument for abandoning the whole 'points' mess and simply stating font size in millimetres.)
Rantings by GNOME fanboys shouldn't be confused with real legal difficulties. As far as I can tell there's zero overlap between fanboys and developers. Besides, GIMP isn't really part of GNOME, it just got adopted in some vague way because it uses GTK. As far as I know it still doesn't use the GNOME libraries.
Pretty much every app has the problem. Haven't you noticed dialogue boxes and icons getting smaller as the resolution of the screen increases?
The trouble with the port made three years ago was that it wasn't allowed by the GPL. As you know, you're not allowed to mix GPLed code with non-GPLed code, and at that time Qt was not GPLed. It's nothing about the GIMP developers being particularly awkward; the same applies to any GPLed program. And when the copyright is held by many different people, it's not easy to get all of them together to grant an exception to the licence.
:-(.
Perhaps you think the GIMP developers were being silly to use the GPL, and they should have used the LGPL instead to allow linking with non-GPLed libraries. But then the KDE developers and thousands of other projects are just the same in this regard. (For example, it would not be legal to port KWord to Motif unless you had explicit permission from all copyright holders. Not that you'd probably want to do this - it's just another example of wanting to port a program to a different widget set, and being stopped by the copying conditions.)
But now that Qt is available under the GPL, it would be legal to distribute KIMP. But the code hasn't reappeared
The trouble is there are still a lot of apps that specify things in pixel sizes rather than in real units (centimetres) or some other scalable unit (fraction of the total display size). So even if you increase the font size - and that would require a system with fonts that aren't ugly, so you're not forced to use a few predefined bitmaps - you may find everything else is too small.
It'll be great when everything uses SVG icons which are rendered at the size you choose and at the right resolution for the display, but that day is a way off yet.