Look at what happened with SSH if you want similar example. If you are the original author (so the copyright is yours) of a GPL project then then you are perfectly entitled to produce a closed source version at some point in the future. It's other people who get the code via the GPL licence who are forced to keep it free.
Passwords often have to be at least 6 characters long which is just about the largest thing that people will be able to memorise. Often, drachonian admins force people to change their passwords every few months forcing users to commit yet another password to memory so they end up using things that they already know well as passwords. At least the people wern't writing them down on post it notes (even if they were doing the next worst thing). Jakob Nielsen wrote a bit about this in Security and Human Factors.
I remember reading about how one of the most popular passwords in the 80s was fred because it was easy to remember and all four keys were close together.
I use ssh (and it's associated utilities) exclusively when logging into remote boxes non-annoymously. A few years ago somone showed me how very easy it was to sniff traffic and I've been more careful ever since.
The OSX default shell is csh
on
Penguin2Apple
·
· Score: 1
The OSX shell isn't really that different to a Linux shell. It was just that the default shell is csh which defaults to trying to be helpful and clever. Personally I can't stand this - I guess I've just come to rely on the dumb consistency of bash.
I believe Mandrake could do this in the past - I still have a copy of 7.2 on my Mum P200. My experience was that the system would run too slowly (even the swap was a file) for people to be bothered to use it regularly. Oh yeah, SUSE have a run off CDROM distro that does something similar. Add to this that they tend to only work with FAT (I believe NTFS writing is still unstable) and you realise that this isn't such a viable solution after all.
I don't think you can reasonably compare the attendence a a highly influential political figure at a product launch to a public speaking engagement. The whole reasoning of attending is to hear Alan speak about Linux - not to buy services from BT. You are unlikely to hear Alan endorsing any thing by BT at the event. I severely doubt it was BT's publicity arm that asked Alan rather it was IT network Wales to whose events BT often sponser. In short I think that saying there is a link between Alan and BT is tenuous at best.
...and they also do it faster but Newsnow isn't nearly as big or as popular as Google. They also seem to aggregate more sources than google (slashdot is aggregated for example).
However, it was difficult to pin down the culprit and now the problem *has* been fixed proving that the the decentralisation of Linux does work, albeit slowly when there isn't outside help. I suppose you can point to FreeBSD as an example that management does help but even over there not everyone knows about it and mistakes are made.
The problem was nobody knew exactly where this was happening. Things like the properitry NVidia drivers are frowned upon for not being open (fair enough - it makes it more difficult to tell where bugs are) because it's difficult to prove they are not buggy. Ironically, it was these drivers that were helping to show up this bug. In the end it took people from within NVidia who could check their own code is correct to file this bug simply because they were in the best position to verify it.
I've posted this elsewhere but to clarify - it looks like this will still happen regardless of which processor you have selected (even i386!). This is because the test for whether your processor does pse seems to be run on startup (I think it's done by arch/i386/mm/init.c __init pagetable_init).
As an aside, as far as I can tell the only (extra) things that optimising a kernel for a K7 seems to set are gcc options (someone please correct me if I'm wrong).
I've posted some quake 3 benchmarks and it looks like the difference may not be significant (less than a half percent). However this is by no means a good test of a heavily loaded system (i.e. a high load average), nor does it test the effect when memory is tight (which is when I guess more paging would take place and the change would be more noticible).
Quake 3 demo was run with \timedemo 1 and \demo DEMO001 . Each test was run three times. The system load average was < 0.5 before Quake 3 was run.
Without mem=nopentium
FPS = 79.4 (79.4, 79.4, 79.4)
With mem=nopentium
FPS = 79.2 (79.1, 79.3, 79.2)
System tested:
Athlon 850, 384MB RAM, Geforce 1 DDR, VIA KT133 Chipset
Athlon/Duron/K7 optimised 2.4.17 kernel (optimising the kernel above pentium makes very little difference though)
NVidia 1.0-2313 video drivers using agpgart
Mandrake 8.0
Quake 3 settings
Texture depth = 16 bits
Colour depth = 16 bits
Geometric detail = High
Texture detail = High
Dynamic lights = On
Video mode = 1024x768
Looks like there is a difference but it's very slight (0.003%) but my benchmarks aren't very scientific. Either way, if there is an improvement in stability this tradeoff is easily worth it. Here's hoping that you don't run linux just for it's Quake 3 scores though...
Almost definitely not. It sounds like the existence of this bug was not known until recently and K7 options almost definitely enable all memory enhancements.
I have an Athlon 850 with a Geforce 1. I thought I had finally gotten rid of the last of the system workarounds when I upgraded my BIOS and I stopped seeing "Stomping on Athlon bug" (the classic VIA chipset problem). Looks like this isn't going to be the case after all.
I have always compiled my kernel for Athlon optimisations and I use the NVidia linux drivers with agpgart. How come I haven't hit this bug before?
How much performance is knocked off the system as whole because of this? Is it a few percent? I presume this will hit all applications not just AGP ones...
I use OpenBSD on a 486 to act as a router on my house's cable modem network. So far it seems to have done a fair job (with the odd lockup - there is never anything in the logs so I can't tell whether it's hardware or software).
However my beef is that the 486 only has a 200Mb hard drive and 24Mb of ram. Since all of OpenBSD's security patches are distributed as source code patches this requires me to be able to rebuild the binaries to fix the wholes. There are no binary updates or patches so keeping such a system up to date after a major releases is actually quite a lot of work (I rebuild the kernel but I stop at that).
If (reliable) updated binaries for i386 architectures were provided then I would be happier to recommened this to peole using low end hardware.
You don't mention which distribution you are using... I noticed that on one of the Mandrake forums someone had found that setting nobiospnp fixed the problem on their KT266A system.
Slashdot Mirror
Look at what happened with SSH if you want similar example. If you are the original author (so the copyright is yours) of a GPL project then then you are perfectly entitled to produce a closed source version at some point in the future. It's other people who get the code via the GPL licence who are forced to keep it free.
Passwords often have to be at least 6 characters long which is just about the largest thing that people will be able to memorise. Often, drachonian admins force people to change their passwords every few months forcing users to commit yet another password to memory so they end up using things that they already know well as passwords. At least the people wern't writing them down on post it notes (even if they were doing the next worst thing). Jakob Nielsen wrote a bit about this in Security and Human Factors.
I remember reading about how one of the most popular passwords in the 80s was fred because it was easy to remember and all four keys were close together.
I use ssh (and it's associated utilities) exclusively when logging into remote boxes non-annoymously. A few years ago somone showed me how very easy it was to sniff traffic and I've been more careful ever since.
The OSX shell isn't really that different to a Linux shell. It was just that the default shell is csh which defaults to trying to be helpful and clever. Personally I can't stand this - I guess I've just come to rely on the dumb consistency of bash.
Obviously, if he was using KDE then of course Konqueror will start quickly but if it was Gnome it's difficult to be beat Galeon.
Was he using one of the major desktop environments (which would have had various libraries preloaded) or was he using something neutral?
Dilo if you don't mind imperfect rendering (doesn't do frames yet).
If you don't mind having a text only interface, Lynx and Links are both good and surprisingly functional.
Of course fast does not necessarily imply best but it's a welcome addition.
Are you sure it is fixed at all? How could this have been fixed in 2.4.18-pre1 when the bug was first discovered when 2.4.18-pre7 was out?
I think I'll keep mem=nopentium until someone can point me to a changelog entry that mentions this directly.
I can't help wandering whether these havesters respect robots.txt though...
I believe Mandrake could do this in the past - I still have a copy of 7.2 on my Mum P200. My experience was that the system would run too slowly (even the swap was a file) for people to be bothered to use it regularly. Oh yeah, SUSE have a run off CDROM distro that does something similar. Add to this that they tend to only work with FAT (I believe NTFS writing is still unstable) and you realise that this isn't such a viable solution after all.
I don't think you can reasonably compare the attendence a a highly influential political figure at a product launch to a public speaking engagement. The whole reasoning of attending is to hear Alan speak about Linux - not to buy services from BT. You are unlikely to hear Alan endorsing any thing by BT at the event. I severely doubt it was BT's publicity arm that asked Alan rather it was IT network Wales to whose events BT often sponser. In short I think that saying there is a link between Alan and BT is tenuous at best.
Odds are Alan won't get paid for this - BT are probably footing the bill for the Taliesen rather than speakers fees...
...to this day.
...instead of confetti?
Best wishes on the marriage Rob!
...and they also do it faster but Newsnow isn't nearly as big or as popular as Google. They also seem to aggregate more sources than google (slashdot is aggregated for example).
However, it was difficult to pin down the culprit and now the problem *has* been fixed proving that the the decentralisation of Linux does work, albeit slowly when there isn't outside help. I suppose you can point to FreeBSD as an example that management does help but even over there not everyone knows about it and mistakes are made.
The problem was nobody knew exactly where this was happening. Things like the properitry NVidia drivers are frowned upon for not being open (fair enough - it makes it more difficult to tell where bugs are) because it's difficult to prove they are not buggy. Ironically, it was these drivers that were helping to show up this bug. In the end it took people from within NVidia who could check their own code is correct to file this bug simply because they were in the best position to verify it.
I've posted this elsewhere but to clarify - it looks like this will still happen regardless of which processor you have selected (even i386!). This is because the test for whether your processor does pse seems to be run on startup (I think it's done by arch/i386/mm/init.c __init pagetable_init).
As an aside, as far as I can tell the only (extra) things that optimising a kernel for a K7 seems to set are gcc options (someone please correct me if I'm wrong).
I've posted some quake 3 benchmarks and it looks like the difference may not be significant (less than a half percent). However this is by no means a good test of a heavily loaded system (i.e. a high load average), nor does it test the effect when memory is tight (which is when I guess more paging would take place and the change would be more noticible).
Shessh - that was quite a mistake (didn't multiply by 100). Man I hope nobody hires me for my mathematical ability...
You may want to take a look at the benchmarks posted later.
Quake 3 demo was run with \timedemo 1 and \demo DEMO001 . Each test was run three times. The system load average was < 0.5 before Quake 3 was run.
Without mem=nopentium
FPS = 79.4 (79.4, 79.4, 79.4)
With mem=nopentium
FPS = 79.2 (79.1, 79.3, 79.2)
System tested:
Athlon 850, 384MB RAM, Geforce 1 DDR, VIA KT133 Chipset
Athlon/Duron/K7 optimised 2.4.17 kernel (optimising the kernel above pentium makes very little difference though)
NVidia 1.0-2313 video drivers using agpgart
Mandrake 8.0
Quake 3 settings
Texture depth = 16 bits
Colour depth = 16 bits
Geometric detail = High
Texture detail = High
Dynamic lights = On
Video mode = 1024x768
Looks like there is a difference but it's very slight (0.003%) but my benchmarks aren't very scientific. Either way, if there is an improvement in stability this tradeoff is easily worth it. Here's hoping that you don't run linux just for it's Quake 3 scores though...
Almost definitely not. It sounds like the existence of this bug was not known until recently and K7 options almost definitely enable all memory enhancements.
I have an Athlon 850 with a Geforce 1. I thought I had finally gotten rid of the last of the system workarounds when I upgraded my BIOS and I stopped seeing "Stomping on Athlon bug" (the classic VIA chipset problem). Looks like this isn't going to be the case after all.
I have always compiled my kernel for Athlon optimisations and I use the NVidia linux drivers with agpgart. How come I haven't hit this bug before?
How much performance is knocked off the system as whole because of this? Is it a few percent? I presume this will hit all applications not just AGP ones...
I'm in my final year at university and my project is a coursework submission program which I will hopefully have plagurism detection built in...
I wonder if anyone will notice if I just borrow some the code from the Georgia one...
I use OpenBSD on a 486 to act as a router on my house's cable modem network. So far it seems to have done a fair job (with the odd lockup - there is never anything in the logs so I can't tell whether it's hardware or software).
However my beef is that the 486 only has a 200Mb hard drive and 24Mb of ram. Since all of OpenBSD's security patches are distributed as source code patches this requires me to be able to rebuild the binaries to fix the wholes. There are no binary updates or patches so keeping such a system up to date after a major releases is actually quite a lot of work (I rebuild the kernel but I stop at that).
If (reliable) updated binaries for i386 architectures were provided then I would be happier to recommened this to peole using low end hardware.
You don't mention which distribution you are using... I noticed that on one of the Mandrake forums someone had found that setting nobiospnp fixed the problem on their KT266A system.