Heh, I should know better than using a figure from memory on Slashdot without checking it first.:) A 7-character password does work out in the range of a few days to exhaust the whole search space.
Although I'm not sure about your figures either; assuming your figure for the number of permutations is correct:
Contrast this to adding a bit to the hash length. I can keep the hash roughly the same speed but double the time to crack.
Really? When you're brute-forcing a password, usually what you're doing is this (simplified but it's the basic idea):
Generate string
Hash string
Compare hash to what is stored in the password database
Repeat until computed hash and stored hash match
So I don't see how increasing the hash length can be more secure, if computing that longer hash takes the same time as a shorter hash. When cracking passwords you are doing exactly the same operation as when the login program is legitimately checking against the password database.
Yes, you can increase the length of the password, and yes, that will make brute-forcing take longer because the cracker has to test more possible passwords, but you try to get users to remember a very long passphrase exactly. But this is the point of this article, we need alternatives to this. Users will end up writing their password down somewhere if it's long and.. poof... there goes any semblance of security.
So unfortunately the only way to make it more secure is to increase the complexity of the hash algorithm, which as you rightly say has knock-on effects.
Imagine a POP3 server with 20 new sessions per second. It'd take a second to verify each connections POP session!
Increases in computing power will eventually make that moot, although as that happens the hashing algorithm becomes less secure again, and we're back to square 1.:(
If your password is in a dictonary, no matter what hashing algo you use, I can brute force it in a few seconds.
You're only thinking in terms of existing hash algorithms. My ancient PIII can compute several million MD5 hashes a second, so it's not surprising that I can brute-force an 8-character password in a day or so.
But what if there was a new hashing algorithm, which even on a very fast computer could only compute one hash a second? That same 8-character password would take many, many years to brute-force - far too long for it to be of any use. So the solution is simple - just increase the computational expense of computing the hash, and the problem is solved.
Of course this doesn't fix other weaknesses with authentication, like people writing down their passwords, extracting them through social engineering or your local friendly blackhat capturing them using a keylogger, but those problems have been with us forever and increasing computer speed makes no difference at all to them.
a simpler solution would be to make the password hashing algorithm much more complex and CPU-intensive.
MD5 and SHA1 are just too fast. If a new hashing algorithm was used that took a second to compute rather than the microsecond or less that an MD5 hash takes, it would make brute-force or dictionary attacks on the password much much more difficult, but wouldn't really get in the way of people logging in - it's only a second.
I wonder how they deal with upgrades to DLLs where the the upgrade represents a security fix.
Well I have no idea if they do this, but one way would be to allow security fixes to invalidate certain DLL versions, so that when an app asks for a certain DLL version, rather than getting that it gets the next best 'safe' DLL version that's available.
It's not perfect - it means that library versions still change underneath an application when a security fix is required, but it would work as long as developers are careful not to break things when doing the security fix.
I currently have the Windows versions of GIMP and Gaim running on my Windows 2000 machine, and they both use the Windows port of GTK+.
While I'm sure that the GIMP and Gaim work just fine under GTK/Win32, do they automatically look and feel like native Windows applications? No, they default to looking like Motif or the GTK 2.0 default theme, just like GTK does on Linux. Do they inherit Windows' fonts and colour scheme? No. Do they automatically adapt to Windows XP's different visual styles? No. There are a whole host of similar little issues regarding integration with Windows. Most apply to the MacOS X port too.
These might seem like small issues, but to a commercial software developer they could easily be the difference between people buying your app and not buying your app. This is why earlier in my previous comment I was careful to say that GTK/gtkmm is probably not acceptable to commercial software developers on Windows and MacOS.
That is my concern with KDE's licensing - that KDE may be forcing the larger developer community away through its use of Qt. Although feel free to prove me wrong:)
Ok, imagine you're a commercial software developer. Right now you're employing 8 developers on $60000 a year. 5 of those are working on the main Windows version of your app, written in MFC, the other 3 are keeping your Mac port up-to-date. You spend $1000 per developer per year keeping their tools current.
Total development cost - $488000 per year
You decide you want a Linux port as well, you think the market is ready for it. You take on another 3 developers to do the port. They start porting the app using gtkmm as your toolkit - there's no way in hell you're going to redevelop your apps in C. It's quite easy to port from MFC, and you find that once you port you're a little more productive using gtkmm than MFC. However, you continue to develop the MFC version as your main version, because gtkmm is not acceptable to you under Windows or MacOS. You aren't paying for your Linux developer tools, but you're still paying $1000 per year for tools for your Windows and Mac developers.
Total development cost - $668000 per year
You try a different tack. You use Qt. You dump the 3 developers doing the Mac port, and the 3 developers doing the Linux port because you don't need them any more. The same source tree that produces your Windows app produces perfectly-functioning and native-looking Mac and Linux apps with nothing more than a recompile. It's a fairly short rewrite from MFC to Qt, and once your developers get used to it, they're a little more productive than with MFC. You spend $3000 per developer per year keeping their tools up to date.
Total development cost - $315000 per year
Tell me again why commercial developers shouldn't like Qt? It's a little more capital outlay to begin with, but it gives you essentially free ports to the other two important OSes. GTK's a long way from being able to do that acceptably. GTK/gtkmm is a fine option if you are intending to develop commercially only for Unix/X11, but how many developers do you know who are willing to do that?
P.S. Where can you buy support contracts for GTK+ and gtkmm, and how much do they cost?
2.6 is going to break tons of apps that aren't recompiled.
Nonsense. 2.6 will break binary-only kernel modules (e.g. the kernel part of the Nvidia driver) but almost all apps don't go anywhere near kernel space, hence almost all binaries will continue to work in 2.6, just like they did after all the previous major kernel upgrades. Apps are shielded from changes in the kernel by libc and ioctl interfaces.
If an app goes anywhere near kernel space directly then it's doing something wrong, with the possible exception of VMWare which requires a kernel module to work at all.
Kernel modules aside, Linux has pretty good binary backwards compatibilty. I have no problems running old libc5 software that's 8 years old, and with extra compatibility libraries could run binaries that hark all the way back to the very earliest days of Linux. That's about as good as Solaris gets with its SunOS 4.x compatibility.
Pentium could run your existing '486 code faster than your '486 without recompiling.
Not significantly faster. The Pentium required compiler support to keep its two integer pipelines filled. Without that support it really wasn't any faster than a 486 - the integer pipelines were all but identical to the one on the 486. The Pentium had a faster external bus and more L1 cache, but the 486 had higher clockspeeds.
It was a bit of a disappointment really - at launch the 486DX4-75 kept up with the 66MHz Pentium, the 486DX4-100 spanked it, and the 486s were cheaper. Then the compiler support came, and the Pentiums started shifting.
Then they did it again with the PPro, which ran old 16-bit code much slower than the Pentium, although it was crazyfast for everything else (and still, IMHO, Intel's nicest CPU).
Then they did it again with the P4, which runs x87 FP code way slower than the P3 or Athlon and had to wait for compilers to generate SSE2 code before showing its potential.
Intel has a history of doing this, and I fully expect things to get better for the Itanium once compiler support improves. The situation is, in all sorts of ways, similar to how things were when the PPro came out - the CPU doesn't run old code well, it's power hungry, very expensive, marketed as a server CPU but still not selling. The PPro was also the last really major design departure before the Itanium.
The difference is that when the PPro came out, Intel didn't have AMD threatening to walk off with the technology leadership. While Intel was turning the unfashionable PPro into the very fashionable PII, AMD was still selling unimpressive 486s and K5s and was in the process of buying NexGen for the 6x86/K6. This time AMD has a whole lot more to bring to the table.
Most non-technical users don't configure anything. They just don't see the need. If it works, why change it? Witness the enormous number of Windows users who have MSN as their IE homepage, who have Tahoma (or Arial for older Windows versions) as font, and who have the standard icky-turquoise, blue, or Teletubbyland backgrounds.
Hence, as long as the defaults are right, there's no great need to spend months umming and ahhing over just how configurable the interface should be, because most of your users won't even bother looking for the controls, they'll just take what they're given. Let's call these people the appliance users, because they tend to treat a computer as a simple appliance to get a few simple tasks done, and outside of doing those tasks they tend not to play much (apart from Solitaire and Minesweeper!). Some of these people are probably better off with a simple appliance-like interface like OEone, rather than a classical WIMP interface. Altogether, the appliance users are maybe 85% of all computer users, possibly more.
On the other hand, it seems as though technically-minded users prefer greater configurability rather than less. They do not mind spending half a day setting up their work environment, because they feel it gives them extra comfort and productivity in the long run, or simply because 'it's cool to make things work the way I want them to'. Let's call them power users, because frankly, that's what they are. This group is somewhere between 5-10% of all computer users, but are by far the most influential on the purchasing decisions of others because of their knowledge about computers.
Then there is a third large group, who sit somewhere in the middle. This group looks for a modicum of flexibility but also looks for a sane set of defaults, enough customizability to make a GUI their own but also to have an environment which 'just works' to get on with the things that they need to do. Let's call these people the 'happy medium' users. These users probably make up somewhere between 5-10% of all computer users, a similar figure to the power users. Apple specializes in catering to this group of users, and probably has a hold on half the users that belong to this group. With MacOS X, Apple have begun to branch out into catering for power users too.
This is what I don't understand about Gnome 2's change in direction: all the major GUIs make an effort to satisfy the applicance users simply by having an initial interface that's not too overwhelming and by having a sound set of defaults. Linux GUIs have made great strides towards satisfying this group in the last year or two - I think there's not much to choose between KDE and Gnome for this group, to be honest. Linux GUIs have, previously, always been good at satisfying the power users. However, Gnome 2 appears to have all but dropped support for power users in favour of catering for 'happy medium' users.
This doesn't make good strategic sense. They have dropped support for one group (power users) in favour of another group, less influential on computing purchasing decisions ('happy medium' users) of approximately the same size. They haven't gained any numbers in doing so, but instead have upset and annoyed a lot of their existing users, most of whom were influential 'power users'.
And why have Gnome done this? Sadly I think it is because their usability team is in awe (for evidence, see for example the essentially pointless button order switch to copy Apple's way of doing it) of what Apple has done with their GUI but don't understand that Apple is a niche player with a GUI that is heavily adapted towards their target market - the 'happy medium' user.
This is why I cringe whenever I see usability engineers talking about Apple all the time. Sure, MacOS has a nice GUI, but without understanding the reasons why Apple took the decisions which make it a nice GUI and the context in which those decisions were taken, you have learnt very little about it at all.
Yeah, it's a shame that XFree86's monitor database doesn't include the physical dimensions of the monitor so it can set the dpi correctly.
Err, if you have XFree86 4.x setup to use DDC to get the available video modes from your monitor, it does exactly this. My screen is running at 86x84dpi (yes it can handle separate x and y dpi settings). Scalable fonts... scale to match.
For compatibility reasons most distros override this and explicitly set 100dpi in startx or in the xdm/kdm/gdm Xservers file - a number of monitors report their screen dimensions incorrectly or don't support DDC or the video card driver doesn't support DDC, certain old software expects either 100dpi or 75dpi, and of course X's bitmap fonts are only available in 75 and 100dpi sizes. But, assuming your monitor reports its size correctly over DDC, your video driver can handle that, and you use mostly scalable fonts, then you can remove the override.
Symbian is not supposed to be competing with the phone companies it's working with them.
Hence why there are two user-interface platforms competing on Symbian, Symbian's UIQ, and Nokia's Series 60, which very much are competing with each other.
Symbian is a strange company. Partly it's an independent software developer like any other, partly it's a collaboration group between the big phone manufacturers, and all the manufacturers have their own vision of the future. When one manufacturer disagrees with the majority view, well that manufacturer goes off and does their own thing, while Symbian implements the wishes of the majority. Which is why you get the situation where Symbian competes with a company that partly owns it. It's very much at the mercy of the corporate egos that own it, and consequently is riddled with inter-owner politics.
Nokia and particularly Ericsson have always been very keen on the idea of Symbian. If you'll excuse the wild conspiracy theory... I think they see it as an opportunity to control the other manufacturers so that none of them can ever threaten their leading position. They were the first phone manufacturers to get on board, they were the first manufacturers with Symbian phones, and between them they own over half of Symbian. I think their plan is to make it a standard, then ratchet up the pricing and direct development in a way that suits them - by which time it'd be difficult to put together a competitive platform without huge resources. A classic Microsoft-ish lock-in strategy. Motorola decided to hedge their bets and play along, but it looks like they don't want to play that game any more - they have a smaller stake in Symbian as they got in later and they don't have the same fairly cordial relations that Nokia and Ericsson have with each other. Can we start calling them the Nordic Mafia yet?
I think Motorola will hold onto its stake in Symbian though even though they now appear not to be using the software, both to keep a controlling hand in it and to piss Nokia and Ericsson off.
Linux will have to run as a separate task in a real-time kernel. And to do so will require a more powerful processor which of course requires more either a much-larger lithium ion battery, or something revolutionary like fuel cells.
Or a more efficient but faster processor. You've heard of Moore's Law right? Use a smaller feature size, maximum clock speed goes up, power consumption goes down. These phones are going to have to be more powerful anyway, they're going to be expected to drive colour displays that can play video and run Java games at decent speeds. If you've got a processor that can do that then the extra overhead of RTLinux or RTAI or LXRT to give you sub-microsecond interrupt response is pretty minimal.
Note that Symbian is only available on high-end phones right now too, but it's expected to trickle down to the lower-end once the processors, memory and screens that can handle its requirements become cheaper. Symbian isn't really any lighter than a properly-stripped Linux anyway, it needs at least 8MB RAM to be properly usable and prefers a lot more.
Would you care to elaborate on how Linux is perfect for embedded systems?
Because it's easy to strip it down to the absolute bare minimum you need - you get all the code. For the same reason it's easy to bugfix. It's robust and well tested. It's fast. With the preemptible kernel patch it does soft real-time very well, and can do hard real-time with other extensions. It has device drivers coming out of its ears. It supports all the same APIs that full-blown desktop/server Linux does, so you can develop and test the application software on a Linux PC and then it'll run on your embedded system. This also means there's enormous quantities of pre-written software you can use to help out, and most of it is free. It's ported to every CPU architecture you can think of, and probably a few you can't. If you don't have an MMU, well, there are versions of Linux that can do without. Most importantly of all, it's either free or cheap, depending on whether you do the work stripping it down yourself or whether you get an embedded Linux vendor to do it for you.
The only real black mark against it as an embedded OS is the lack of hard real-time as standard, but this is fixable, and irrelevant to most embedded apps anyway. Otherwise, yes, it is pretty much perfect for embedded systems. Why do you think it's doing so well?:)
Who cares what OS is running underneath if the software subjects you to hellish reams of menus and extra buttons when competing phones from Nokia or whoever just seem to work with a few clicks?
You do get used to them, and they all have a quick-access menu for the most common functions, although I agree they're a real pain when you want to do something that's not on the quick-access menu. The most recent Motorola phones have improved a heck of a lot though, to the point where they're better than most Ericssons at least (5 submenus to divert all calls on a T39! 5!), even if they're not quite up to Nokia's (or Samsung's - very impressed with their menu system) standards.
The supposed problem with them was that their GSM development team was a bit low-priority until recently, because GSM wasn't big in the US... their US TDMA, CDMA and iDEN phones have always been better. Of course that's changing now given the move towards GSM in the US, and surprise surprise, their GSM phones are getting easier to use.
One nice thing about Motorolas is that their software has always been rock-solid stable, unlike some Finnish manufacturers...
It all makes sense: Let one division of motorola use the chips that the other division produces.
Mmmm perhaps you have a point. Practically all phones today, including all of Motorola's, run on some kind of ARM variant... and Symbian is only targetting ARM as a platform. It might be exactly the reason they went with Linux rather than Symbian - so they can use their own CPU designs instead.
That said, Motorola is a large enough potential customer that Symbian would probably port to any architecture they asked without hesitation. I don't think Motorola has any CPU that's comparable to an ARM7 either, all the PPCs are too power-hungry for a mobile phone and all their other lines (e.g. 68k, Coldfire) are too slow.
I'd be interested in what kind of hardware they are using.
Well it'll be custom-designed, without a doubt. I don't think anyone makes standardized hardware modules for mobile phones and sells them on the open market, the design constraints vary too much from phone to phone. I know someone who does PCB design for mobile phones - he is seriously in demand, there's a big shortage of people with the right skillset for it - and he tells me that most of the time it's a new PCB for each model, and they're very very cramped and complicated designs.
Almost certainly the hardware will be based around an ARM7 variant - probably an ARM720T as it has an MMU - as they're simply the best for the job, lowest power for the most MIPS, but that's about as standard as it gets. The radio interface, and probably everything else, will be Motorola's own design.
If you want to build your own phone which competes with commercial designs, you're going to have to learn micro-PCB design or contract out to someone who can, and you'll probably have to accept that some of the components (e.g. the radio interface) won't be as good as the big manufacturers' designs. Sorry, but that's the way it is.:(
And when speaking about Java applets running on phones. That has been done by both Ericsson and Nokia for a while now.
As indeed they have been on Motorola phones.
I believe they were the first in fact, on a US iDEN phone a couple of years ago, which hosted it on VxWorks.
It's good for Java, but Motorola had already committed quite heavily to Java on their phones - heck, you can't move for Motorola adverts promoting Java games on their phones on UK TV right now - just everyone expected them to choose Symbian as the platform for running Java on their next-gen phones, so this is quite a surprise.
You're right that it probably won't give Linux any end-user visibility, but it's still a big win, and it gives embedded Linux vendors a big name they can point at and say to their potential customers - "Look, they chose Linux, why don't you?". Good for MontaVista, good for other embedded Linux vendors, good for Linux as a whole.
Come one, it's got linux in the title, does that make it news?
You bet it is. One of the big three mobile phone manufacturers has said it's not going to be following the rest of the herd with Symbian but is going with an alternative. That in itself is huge news - the mobile phone market is gigantic - almost certainly the single most important embedded software market - and Symbian was expected to walk it, and win over every major manufacturer. Instead, as we see, it's not. Even without looking at it from a Linux perspective, it's a big thing.
At the same time, from a Linux perspective, it's even bigger. It's an enormous win, it'll keep MontaVista and their partners afloat for years. It's also a huge boost to Linux's status in the embedded world - a manufacturer as large as Motorola doesn't choose an OS for their phones lightly. This is a market Microsoft has been spending hand over fist to get into, and failing apart from with a few niche players (one of whom, Sendo, very publicly dumped Microsoft for Symbian)... and yet Linux waltzes in with no budget behind it and captures a Big Three manufacturer without even trying, and in the face of competition from Symbian who have a very very sharp phone OS of their own.
Pretty hard to do, constructing more tunnels under London is a hard thing to do
But that still leaves the option of running trains more frequently, and that doesn't involve building new tunnels. You just need to upgrade the signalling systems. It's expensive work but nothing like building a new line.
At peak times it's about a train every 60-90 seconds on most lines, better signalling systems could reduce that to about 30 - hey presto, doubled capacity.
Unfortunately PPP has probably put paid to that happening any time soon...:(
SF is onlly 7.5 miles across east to west? And it takes more than 10 minutes to get there? Traffic must be awful.
To give you some idea of how bad London's traffic problems are, if you travelled at the average morning rush-hour traffic speed, a 7.5 mile journey across London would take you 37 and a half minutes.
That system seems a bit clumsy. It sounds fairly expensive, too.
Not really. Most of the cameras were already in place for traffic-flow monitoring, all it required was a few more to patch up the gaps in coverage and some new software to interpret the images. A smart card system would have required every driver - even those who only drove into London once in ten years - to buy an expensive smart card reader/transmitter. Maybe you can get away with that in Singapore, but forking out money so that you get charged for the privilege? Not in London.
OK so the London government could buy the smartcard reader/transponders but then you're spending far far more on infrastructure than you are on a few hundred cameras, plus you have to work out a way to distribute them. Also it would have been susceptible to tampering - look at the dismal failure that most satellite TV smart card systems are. You could easily have a PC sitting in your car pretending to be a smartcard but failing to deduct any money. Also how do you enforce a smart card system? What happens when a car enters the charging zone without a smart card? You can't have barriers to stop these cars, the whole point of the system is to improve traffic flow, not slow it down, same reason you can't have toll booths. Only way is to have... enforcement cameras everywhere. Real cost saving eh?
Your choice: enforcement cameras plus some relatively cheap software, all centrally controlled and essentially tamper-proof... or enforcement cameras plus several million expensive hardware smartcards and transponders, only limited central control, and prone to tampering.
Smart card/transponder systems work on public transport because there are barriers in the way to stop you if you don't have one or it's run out of money - as a matter of fact London is getting just such a system this year. But for a road system they're simply the wrong technology.
Adjust the button order programmatically depending on what environment the app is running in.
When running in KDE, GNOME/GTK+ programs should adopt the KDE button conventions (and possibly other UI choices).
When running in GNOME, KDE/Qt programs should adopt the GNOME conventions.
For KDE apps at least, this is relatively simple - much of the KDE user interface style is already programmatically enforced. Switching button order on dialogs (that inherit KDialogBase, and that's most of them) is a one-liner, a few more lines if it's to be run-time configurable. Similarly, changing menu and toolbar conventions/layout involves using a different XML file to merge with - hey presto, all the menus and toolbar buttons in all KDE apps are arranged differently.
I don't know how easy this would be from a GNOME perspective - my guess is, at least for the button ordering, quite easy - the switch before GNOME2 was released didn't seem to take very long. As for menu/toolbar conventions, this depends on how many GNOME apps use GLADE rather than hardcoding their interface...
All the Athlon codenames are named after horses or breeds of horses. Duron, Morgan, Palomino, Thoroughbred and indeed Athlon itself are all types of horse.
Barton appears to be named after Sir Barton, the first horse to win the Triple Crown - get the cunning inside joke?
It seems to be little-known fact that fonts and typefaces are not protected by copyright.
That's because this is not quite correct. You should read the site you link to more closely.
There are two separate areas of copyright on a computer font, relating to the design (the shape of the letters), and the vector data - and name - that describes this design.
In the US, the design of a typeface cannot be copyrighted, but the data and name that describes this design can be. Thus, for instance, Monotype can claim copyright over their implementation of Arial, so if you simply copy the.ttf font file without their permission, you are in breach of copyright law. However, if you print out each character of the font extra-large and then scan and trace the shapes to make a new font with a different name, you are okay - in the process of tracing the shape, you have created an original work. This is why there are so many cheap knock-offs of popular typefaces with subtly different names to the original. Funnily enough given the nature of this story, Bitstream are notorious for doing this.
I don't think your idea of creating bitmaps from a scalable font to avoid copyright would pass muster, because you have merely translated the copyrighted data from one form to another - no different to converting the font from TrueType to Type1, for instance. You haven't created an original work.
Note that this rather strange situation only applies to the US - just about everywhere else that enforces copyright allows designers to copyright typeface designs as well as the data that describes the design, so if you make a knock-off of a non-US designer's typeface, you might find yourself in hot water.
Interestingly, the situation dates from the early years of American independence when all the commonly-used typeface designs were owned by foreigners and there was a shortage of skilled typographers to create distinctive American typefaces. To get around this problem, the fledgling US Patent Office simply declared typeface designs uncopyrightable, thus sparing US printers some stiff royalties. Ahhh the irony...
It interesting that the lack of copyright protection has apparently not hindered the creation of a wide variety of fonts.
True, but it should be noted that almost all the important typefaces of the last 200 years have been designed outside of the US... Times, Helvetica, Gill Sans, Futura, Eurostile, Rotis, Palatino, these typefaces are the backbone of modern design, and none of them came from the US.
Slashdot Mirror
Heh, I should know better than using a figure from memory on Slashdot without checking it first. :) A 7-character password does work out in the range of a few days to exhaust the whole search space.
:p
Although I'm not sure about your figures either; assuming your figure for the number of permutations is correct:
218340105584896 / (10000000 * 60 * 60 * 24) = 252.7 days, not 7 years.
Contrast this to adding a bit to the hash length. I can keep the hash roughly the same speed but double the time to crack.
Really? When you're brute-forcing a password, usually what you're doing is this (simplified but it's the basic idea):
So I don't see how increasing the hash length can be more secure, if computing that longer hash takes the same time as a shorter hash. When cracking passwords you are doing exactly the same operation as when the login program is legitimately checking against the password database.
Yes, you can increase the length of the password, and yes, that will make brute-forcing take longer because the cracker has to test more possible passwords, but you try to get users to remember a very long passphrase exactly. But this is the point of this article, we need alternatives to this. Users will end up writing their password down somewhere if it's long and.. poof... there goes any semblance of security.
So unfortunately the only way to make it more secure is to increase the complexity of the hash algorithm, which as you rightly say has knock-on effects.
Imagine a POP3 server with 20 new sessions per second. It'd take a second to verify each connections POP session!
Increases in computing power will eventually make that moot, although as that happens the hashing algorithm becomes less secure again, and we're back to square 1. :(
If your password is in a dictonary, no matter what hashing algo you use, I can brute force it in a few seconds.
You're only thinking in terms of existing hash algorithms. My ancient PIII can compute several million MD5 hashes a second, so it's not surprising that I can brute-force an 8-character password in a day or so.
But what if there was a new hashing algorithm, which even on a very fast computer could only compute one hash a second? That same 8-character password would take many, many years to brute-force - far too long for it to be of any use. So the solution is simple - just increase the computational expense of computing the hash, and the problem is solved.
Of course this doesn't fix other weaknesses with authentication, like people writing down their passwords, extracting them through social engineering or your local friendly blackhat capturing them using a keylogger, but those problems have been with us forever and increasing computer speed makes no difference at all to them.
a simpler solution would be to make the password hashing algorithm much more complex and CPU-intensive.
MD5 and SHA1 are just too fast. If a new hashing algorithm was used that took a second to compute rather than the microsecond or less that an MD5 hash takes, it would make brute-force or dictionary attacks on the password much much more difficult, but wouldn't really get in the way of people logging in - it's only a second.
I wonder how they deal with upgrades to DLLs where the the upgrade represents a security fix.
Well I have no idea if they do this, but one way would be to allow security fixes to invalidate certain DLL versions, so that when an app asks for a certain DLL version, rather than getting that it gets the next best 'safe' DLL version that's available.
It's not perfect - it means that library versions still change underneath an application when a security fix is required, but it would work as long as developers are careful not to break things when doing the security fix.
I currently have the Windows versions of GIMP and Gaim running on my Windows 2000 machine, and they both use the Windows port of GTK+.
While I'm sure that the GIMP and Gaim work just fine under GTK/Win32, do they automatically look and feel like native Windows applications? No, they default to looking like Motif or the GTK 2.0 default theme, just like GTK does on Linux. Do they inherit Windows' fonts and colour scheme? No. Do they automatically adapt to Windows XP's different visual styles? No. There are a whole host of similar little issues regarding integration with Windows. Most apply to the MacOS X port too.
These might seem like small issues, but to a commercial software developer they could easily be the difference between people buying your app and not buying your app. This is why earlier in my previous comment I was careful to say that GTK/gtkmm is probably not acceptable to commercial software developers on Windows and MacOS.
That is my concern with KDE's licensing - that KDE may be forcing the larger developer community away through its use of Qt. Although feel free to prove me wrong :)
Ok, imagine you're a commercial software developer. Right now you're employing 8 developers on $60000 a year. 5 of those are working on the main Windows version of your app, written in MFC, the other 3 are keeping your Mac port up-to-date. You spend $1000 per developer per year keeping their tools current.
Total development cost - $488000 per year
You decide you want a Linux port as well, you think the market is ready for it. You take on another 3 developers to do the port. They start porting the app using gtkmm as your toolkit - there's no way in hell you're going to redevelop your apps in C. It's quite easy to port from MFC, and you find that once you port you're a little more productive using gtkmm than MFC. However, you continue to develop the MFC version as your main version, because gtkmm is not acceptable to you under Windows or MacOS. You aren't paying for your Linux developer tools, but you're still paying $1000 per year for tools for your Windows and Mac developers.
Total development cost - $668000 per year
You try a different tack. You use Qt. You dump the 3 developers doing the Mac port, and the 3 developers doing the Linux port because you don't need them any more. The same source tree that produces your Windows app produces perfectly-functioning and native-looking Mac and Linux apps with nothing more than a recompile. It's a fairly short rewrite from MFC to Qt, and once your developers get used to it, they're a little more productive than with MFC. You spend $3000 per developer per year keeping their tools up to date.
Total development cost - $315000 per year
Tell me again why commercial developers shouldn't like Qt? It's a little more capital outlay to begin with, but it gives you essentially free ports to the other two important OSes. GTK's a long way from being able to do that acceptably. GTK/gtkmm is a fine option if you are intending to develop commercially only for Unix/X11, but how many developers do you know who are willing to do that?
P.S. Where can you buy support contracts for GTK+ and gtkmm, and how much do they cost?
2.6 is going to break tons of apps that aren't recompiled.
Nonsense. 2.6 will break binary-only kernel modules (e.g. the kernel part of the Nvidia driver) but almost all apps don't go anywhere near kernel space, hence almost all binaries will continue to work in 2.6, just like they did after all the previous major kernel upgrades. Apps are shielded from changes in the kernel by libc and ioctl interfaces.
If an app goes anywhere near kernel space directly then it's doing something wrong, with the possible exception of VMWare which requires a kernel module to work at all.
Kernel modules aside, Linux has pretty good binary backwards compatibilty. I have no problems running old libc5 software that's 8 years old, and with extra compatibility libraries could run binaries that hark all the way back to the very earliest days of Linux. That's about as good as Solaris gets with its SunOS 4.x compatibility.
Pentium could run your existing '486 code faster than your '486 without recompiling.
Not significantly faster. The Pentium required compiler support to keep its two integer pipelines filled. Without that support it really wasn't any faster than a 486 - the integer pipelines were all but identical to the one on the 486. The Pentium had a faster external bus and more L1 cache, but the 486 had higher clockspeeds.
It was a bit of a disappointment really - at launch the 486DX4-75 kept up with the 66MHz Pentium, the 486DX4-100 spanked it, and the 486s were cheaper. Then the compiler support came, and the Pentiums started shifting.
Then they did it again with the PPro, which ran old 16-bit code much slower than the Pentium, although it was crazyfast for everything else (and still, IMHO, Intel's nicest CPU).
Then they did it again with the P4, which runs x87 FP code way slower than the P3 or Athlon and had to wait for compilers to generate SSE2 code before showing its potential.
Intel has a history of doing this, and I fully expect things to get better for the Itanium once compiler support improves. The situation is, in all sorts of ways, similar to how things were when the PPro came out - the CPU doesn't run old code well, it's power hungry, very expensive, marketed as a server CPU but still not selling. The PPro was also the last really major design departure before the Itanium.
The difference is that when the PPro came out, Intel didn't have AMD threatening to walk off with the technology leadership. While Intel was turning the unfashionable PPro into the very fashionable PII, AMD was still selling unimpressive 486s and K5s and was in the process of buying NexGen for the 6x86/K6. This time AMD has a whole lot more to bring to the table.
Most non-technical users don't configure anything. They just don't see the need. If it works, why change it? Witness the enormous number of Windows users who have MSN as their IE homepage, who have Tahoma (or Arial for older Windows versions) as font, and who have the standard icky-turquoise, blue, or Teletubbyland backgrounds.
Hence, as long as the defaults are right, there's no great need to spend months umming and ahhing over just how configurable the interface should be, because most of your users won't even bother looking for the controls, they'll just take what they're given. Let's call these people the appliance users, because they tend to treat a computer as a simple appliance to get a few simple tasks done, and outside of doing those tasks they tend not to play much (apart from Solitaire and Minesweeper!). Some of these people are probably better off with a simple appliance-like interface like OEone, rather than a classical WIMP interface. Altogether, the appliance users are maybe 85% of all computer users, possibly more.
On the other hand, it seems as though technically-minded users prefer greater configurability rather than less. They do not mind spending half a day setting up their work environment, because they feel it gives them extra comfort and productivity in the long run, or simply because 'it's cool to make things work the way I want them to'. Let's call them power users, because frankly, that's what they are. This group is somewhere between 5-10% of all computer users, but are by far the most influential on the purchasing decisions of others because of their knowledge about computers.
Then there is a third large group, who sit somewhere in the middle. This group looks for a modicum of flexibility but also looks for a sane set of defaults, enough customizability to make a GUI their own but also to have an environment which 'just works' to get on with the things that they need to do. Let's call these people the 'happy medium' users. These users probably make up somewhere between 5-10% of all computer users, a similar figure to the power users. Apple specializes in catering to this group of users, and probably has a hold on half the users that belong to this group. With MacOS X, Apple have begun to branch out into catering for power users too.
This is what I don't understand about Gnome 2's change in direction: all the major GUIs make an effort to satisfy the applicance users simply by having an initial interface that's not too overwhelming and by having a sound set of defaults. Linux GUIs have made great strides towards satisfying this group in the last year or two - I think there's not much to choose between KDE and Gnome for this group, to be honest. Linux GUIs have, previously, always been good at satisfying the power users. However, Gnome 2 appears to have all but dropped support for power users in favour of catering for 'happy medium' users.
This doesn't make good strategic sense. They have dropped support for one group (power users) in favour of another group, less influential on computing purchasing decisions ('happy medium' users) of approximately the same size. They haven't gained any numbers in doing so, but instead have upset and annoyed a lot of their existing users, most of whom were influential 'power users'.
And why have Gnome done this? Sadly I think it is because their usability team is in awe (for evidence, see for example the essentially pointless button order switch to copy Apple's way of doing it) of what Apple has done with their GUI but don't understand that Apple is a niche player with a GUI that is heavily adapted towards their target market - the 'happy medium' user.
This is why I cringe whenever I see usability engineers talking about Apple all the time. Sure, MacOS has a nice GUI, but without understanding the reasons why Apple took the decisions which make it a nice GUI and the context in which those decisions were taken, you have learnt very little about it at all.
Yeah, it's a shame that XFree86's monitor database doesn't include the physical dimensions of the monitor so it can set the dpi correctly.
Err, if you have XFree86 4.x setup to use DDC to get the available video modes from your monitor, it does exactly this. My screen is running at 86x84dpi (yes it can handle separate x and y dpi settings). Scalable fonts... scale to match.
For compatibility reasons most distros override this and explicitly set 100dpi in startx or in the xdm/kdm/gdm Xservers file - a number of monitors report their screen dimensions incorrectly or don't support DDC or the video card driver doesn't support DDC, certain old software expects either 100dpi or 75dpi, and of course X's bitmap fonts are only available in 75 and 100dpi sizes. But, assuming your monitor reports its size correctly over DDC, your video driver can handle that, and you use mostly scalable fonts, then you can remove the override.
Symbian is not supposed to be competing with the phone companies it's working with them.
Hence why there are two user-interface platforms competing on Symbian, Symbian's UIQ, and Nokia's Series 60, which very much are competing with each other.
Symbian is a strange company. Partly it's an independent software developer like any other, partly it's a collaboration group between the big phone manufacturers, and all the manufacturers have their own vision of the future. When one manufacturer disagrees with the majority view, well that manufacturer goes off and does their own thing, while Symbian implements the wishes of the majority. Which is why you get the situation where Symbian competes with a company that partly owns it. It's very much at the mercy of the corporate egos that own it, and consequently is riddled with inter-owner politics.
Nokia and particularly Ericsson have always been very keen on the idea of Symbian. If you'll excuse the wild conspiracy theory... I think they see it as an opportunity to control the other manufacturers so that none of them can ever threaten their leading position. They were the first phone manufacturers to get on board, they were the first manufacturers with Symbian phones, and between them they own over half of Symbian. I think their plan is to make it a standard, then ratchet up the pricing and direct development in a way that suits them - by which time it'd be difficult to put together a competitive platform without huge resources. A classic Microsoft-ish lock-in strategy. Motorola decided to hedge their bets and play along, but it looks like they don't want to play that game any more - they have a smaller stake in Symbian as they got in later and they don't have the same fairly cordial relations that Nokia and Ericsson have with each other. Can we start calling them the Nordic Mafia yet?
I think Motorola will hold onto its stake in Symbian though even though they now appear not to be using the software, both to keep a controlling hand in it and to piss Nokia and Ericsson off.
Linux will have to run as a separate task in a real-time kernel. And to do so will require a more powerful processor which of course requires more either a much-larger lithium ion battery, or something revolutionary like fuel cells.
Or a more efficient but faster processor. You've heard of Moore's Law right? Use a smaller feature size, maximum clock speed goes up, power consumption goes down. These phones are going to have to be more powerful anyway, they're going to be expected to drive colour displays that can play video and run Java games at decent speeds. If you've got a processor that can do that then the extra overhead of RTLinux or RTAI or LXRT to give you sub-microsecond interrupt response is pretty minimal.
Note that Symbian is only available on high-end phones right now too, but it's expected to trickle down to the lower-end once the processors, memory and screens that can handle its requirements become cheaper. Symbian isn't really any lighter than a properly-stripped Linux anyway, it needs at least 8MB RAM to be properly usable and prefers a lot more.
Would you care to elaborate on how Linux is perfect for embedded systems?
Because it's easy to strip it down to the absolute bare minimum you need - you get all the code. For the same reason it's easy to bugfix. It's robust and well tested. It's fast. With the preemptible kernel patch it does soft real-time very well, and can do hard real-time with other extensions. It has device drivers coming out of its ears. It supports all the same APIs that full-blown desktop/server Linux does, so you can develop and test the application software on a Linux PC and then it'll run on your embedded system. This also means there's enormous quantities of pre-written software you can use to help out, and most of it is free. It's ported to every CPU architecture you can think of, and probably a few you can't. If you don't have an MMU, well, there are versions of Linux that can do without. Most importantly of all, it's either free or cheap, depending on whether you do the work stripping it down yourself or whether you get an embedded Linux vendor to do it for you.
The only real black mark against it as an embedded OS is the lack of hard real-time as standard, but this is fixable, and irrelevant to most embedded apps anyway. Otherwise, yes, it is pretty much perfect for embedded systems. Why do you think it's doing so well? :)
Who cares what OS is running underneath if the software subjects you to hellish reams of menus and extra buttons when competing phones from Nokia or whoever just seem to work with a few clicks?
You do get used to them, and they all have a quick-access menu for the most common functions, although I agree they're a real pain when you want to do something that's not on the quick-access menu. The most recent Motorola phones have improved a heck of a lot though, to the point where they're better than most Ericssons at least (5 submenus to divert all calls on a T39! 5!), even if they're not quite up to Nokia's (or Samsung's - very impressed with their menu system) standards.
The supposed problem with them was that their GSM development team was a bit low-priority until recently, because GSM wasn't big in the US... their US TDMA, CDMA and iDEN phones have always been better. Of course that's changing now given the move towards GSM in the US, and surprise surprise, their GSM phones are getting easier to use.
One nice thing about Motorolas is that their software has always been rock-solid stable, unlike some Finnish manufacturers...
It all makes sense: Let one division of motorola use the chips that the other division produces.
Mmmm perhaps you have a point. Practically all phones today, including all of Motorola's, run on some kind of ARM variant... and Symbian is only targetting ARM as a platform. It might be exactly the reason they went with Linux rather than Symbian - so they can use their own CPU designs instead.
That said, Motorola is a large enough potential customer that Symbian would probably port to any architecture they asked without hesitation. I don't think Motorola has any CPU that's comparable to an ARM7 either, all the PPCs are too power-hungry for a mobile phone and all their other lines (e.g. 68k, Coldfire) are too slow.
I guess we'll see when the phones come out.
I'd be interested in what kind of hardware they are using.
Well it'll be custom-designed, without a doubt. I don't think anyone makes standardized hardware modules for mobile phones and sells them on the open market, the design constraints vary too much from phone to phone. I know someone who does PCB design for mobile phones - he is seriously in demand, there's a big shortage of people with the right skillset for it - and he tells me that most of the time it's a new PCB for each model, and they're very very cramped and complicated designs.
Almost certainly the hardware will be based around an ARM7 variant - probably an ARM720T as it has an MMU - as they're simply the best for the job, lowest power for the most MIPS, but that's about as standard as it gets. The radio interface, and probably everything else, will be Motorola's own design.
If you want to build your own phone which competes with commercial designs, you're going to have to learn micro-PCB design or contract out to someone who can, and you'll probably have to accept that some of the components (e.g. the radio interface) won't be as good as the big manufacturers' designs. Sorry, but that's the way it is. :(
And when speaking about Java applets running on phones. That has been done by both Ericsson and Nokia for a while now.
As indeed they have been on Motorola phones.
I believe they were the first in fact, on a US iDEN phone a couple of years ago, which hosted it on VxWorks.
It's good for Java, but Motorola had already committed quite heavily to Java on their phones - heck, you can't move for Motorola adverts promoting Java games on their phones on UK TV right now - just everyone expected them to choose Symbian as the platform for running Java on their next-gen phones, so this is quite a surprise.
You're right that it probably won't give Linux any end-user visibility, but it's still a big win, and it gives embedded Linux vendors a big name they can point at and say to their potential customers - "Look, they chose Linux, why don't you?". Good for MontaVista, good for other embedded Linux vendors, good for Linux as a whole.
Come one, it's got linux in the title, does that make it news?
You bet it is. One of the big three mobile phone manufacturers has said it's not going to be following the rest of the herd with Symbian but is going with an alternative. That in itself is huge news - the mobile phone market is gigantic - almost certainly the single most important embedded software market - and Symbian was expected to walk it, and win over every major manufacturer. Instead, as we see, it's not. Even without looking at it from a Linux perspective, it's a big thing.
At the same time, from a Linux perspective, it's even bigger. It's an enormous win, it'll keep MontaVista and their partners afloat for years. It's also a huge boost to Linux's status in the embedded world - a manufacturer as large as Motorola doesn't choose an OS for their phones lightly. This is a market Microsoft has been spending hand over fist to get into, and failing apart from with a few niche players (one of whom, Sendo, very publicly dumped Microsoft for Symbian)... and yet Linux waltzes in with no budget behind it and captures a Big Three manufacturer without even trying, and in the face of competition from Symbian who have a very very sharp phone OS of their own.
So yes it's news.
Pretty hard to do, constructing more tunnels under London is a hard thing to do
But that still leaves the option of running trains more frequently, and that doesn't involve building new tunnels. You just need to upgrade the signalling systems. It's expensive work but nothing like building a new line.
At peak times it's about a train every 60-90 seconds on most lines, better signalling systems could reduce that to about 30 - hey presto, doubled capacity.
Unfortunately PPP has probably put paid to that happening any time soon... :(
SF is onlly 7.5 miles across east to west? And it takes more than 10 minutes to get there? Traffic must be awful.
To give you some idea of how bad London's traffic problems are, if you travelled at the average morning rush-hour traffic speed, a 7.5 mile journey across London would take you 37 and a half minutes.
That system seems a bit clumsy. It sounds fairly expensive, too.
Not really. Most of the cameras were already in place for traffic-flow monitoring, all it required was a few more to patch up the gaps in coverage and some new software to interpret the images. A smart card system would have required every driver - even those who only drove into London once in ten years - to buy an expensive smart card reader/transmitter. Maybe you can get away with that in Singapore, but forking out money so that you get charged for the privilege? Not in London.
OK so the London government could buy the smartcard reader/transponders but then you're spending far far more on infrastructure than you are on a few hundred cameras, plus you have to work out a way to distribute them. Also it would have been susceptible to tampering - look at the dismal failure that most satellite TV smart card systems are. You could easily have a PC sitting in your car pretending to be a smartcard but failing to deduct any money. Also how do you enforce a smart card system? What happens when a car enters the charging zone without a smart card? You can't have barriers to stop these cars, the whole point of the system is to improve traffic flow, not slow it down, same reason you can't have toll booths. Only way is to have... enforcement cameras everywhere. Real cost saving eh?
Your choice: enforcement cameras plus some relatively cheap software, all centrally controlled and essentially tamper-proof... or enforcement cameras plus several million expensive hardware smartcards and transponders, only limited central control, and prone to tampering.
Smart card/transponder systems work on public transport because there are barriers in the way to stop you if you don't have one or it's run out of money - as a matter of fact London is getting just such a system this year. But for a road system they're simply the wrong technology.
Adjust the button order programmatically depending on what environment the app is running in.
When running in KDE, GNOME/GTK+ programs should adopt the KDE button conventions (and possibly other UI choices).
When running in GNOME, KDE/Qt programs should adopt the GNOME conventions.
For KDE apps at least, this is relatively simple - much of the KDE user interface style is already programmatically enforced. Switching button order on dialogs (that inherit KDialogBase, and that's most of them) is a one-liner, a few more lines if it's to be run-time configurable. Similarly, changing menu and toolbar conventions/layout involves using a different XML file to merge with - hey presto, all the menus and toolbar buttons in all KDE apps are arranged differently.
I don't know how easy this would be from a GNOME perspective - my guess is, at least for the button ordering, quite easy - the switch before GNOME2 was released didn't seem to take very long. As for menu/toolbar conventions, this depends on how many GNOME apps use GLADE rather than hardcoding their interface...
All the Athlon codenames are named after horses or breeds of horses. Duron, Morgan, Palomino, Thoroughbred and indeed Athlon itself are all types of horse.
Barton appears to be named after Sir Barton, the first horse to win the Triple Crown - get the cunning inside joke?
More info on Sir Barton here.
It seems to be little-known fact that fonts and typefaces are not protected by copyright.
That's because this is not quite correct. You should read the site you link to more closely.
There are two separate areas of copyright on a computer font, relating to the design (the shape of the letters), and the vector data - and name - that describes this design.
In the US, the design of a typeface cannot be copyrighted, but the data and name that describes this design can be. Thus, for instance, Monotype can claim copyright over their implementation of Arial, so if you simply copy the .ttf font file without their permission, you are in breach of copyright law. However, if you print out each character of the font extra-large and then scan and trace the shapes to make a new font with a different name, you are okay - in the process of tracing the shape, you have created an original work. This is why there are so many cheap knock-offs of popular typefaces with subtly different names to the original. Funnily enough given the nature of this story, Bitstream are notorious for doing this.
I don't think your idea of creating bitmaps from a scalable font to avoid copyright would pass muster, because you have merely translated the copyrighted data from one form to another - no different to converting the font from TrueType to Type1, for instance. You haven't created an original work.
Note that this rather strange situation only applies to the US - just about everywhere else that enforces copyright allows designers to copyright typeface designs as well as the data that describes the design, so if you make a knock-off of a non-US designer's typeface, you might find yourself in hot water.
Interestingly, the situation dates from the early years of American independence when all the commonly-used typeface designs were owned by foreigners and there was a shortage of skilled typographers to create distinctive American typefaces. To get around this problem, the fledgling US Patent Office simply declared typeface designs uncopyrightable, thus sparing US printers some stiff royalties. Ahhh the irony...
It interesting that the lack of copyright protection has apparently not hindered the creation of a wide variety of fonts.
True, but it should be noted that almost all the important typefaces of the last 200 years have been designed outside of the US... Times, Helvetica, Gill Sans, Futura, Eurostile, Rotis, Palatino, these typefaces are the backbone of modern design, and none of them came from the US.