Laptop thieves don't care about your data. YOU care about your data.
Unless, like the article states, you're the US Army and you lost track of 600 laptops in the last years. Not every one of them contained highly sensitive info (well, I think), but it's still disturbing to know that somebody else can get access to the information which was on those.
If your data is important enough to you to warrant some kind of wrist gadget, it's probably important enough to somebody else who can try to get access to it by stealing your laptop for the info rather than for the hardware.
First thought I had: just remove the battery when you steal it, so that any gadget inside wouldn't be able to change something on the HDD. But the article says that the files are always encrypted, and only a cached copy (probably in RAM) is used when the user is viewing or modifying a file.
I'm not sure I really understand what you want to do. Let me explain.
Presently, you're a SysAdmin in a Web services company. And you want to change job, to get something less "commercial" and more "big picture", like Science/Research/Academia.
Are you aiming a SysAdmin job in that kind of environment (by opposition to where you are presently), or are you looking forward to do some science/research in a Academia environment? IE, is your target a teacher's or reasearcher's job, or a SysAdmin's job?
You're not asking about actual day to day job differences, just salary and job satisfaction, so I'm inclined to think that you want to remain a SysAdmin, but a confirmation from you could help us better answer your questions.
It's not much for the internal strings (function names, variables, etc.), more for the messages that the kernel can send to the user (or root). For the first kind of strings, you'd have to redefine the C standard, and change compiler (and maybe also change text editor).
When it boots, there's a whole slew of lines, many of which are purely numbers, but some of them could be localized (just as a big part of userland is). Now, since it would be in kernelspace, you'd maybe want to choose which one at compile time, but if you don't have access to a kind of Unicode for outputting strings, your choice of supported languages will be quite small.
Now, this doesn't go in the argument if it's a desired behavior or not, just that it's something necessary before outputting for any language.
Java has some reflexivity. Not as much as Smalltalk, but it has some. For instance, you can query an object class for about anything you want, but you cannot (easily) modify it runtime (add/modify a method).
For more info, check the java.lang.reflect.* documentation.
I'm not enough familiar with it to talk about it's meta-data capabilities.
And besides, usually you don't need that kind of functionnality, unless you're doing academic research on such languages, and then you'd probably use Scheme or Smalltalk anyway...
Then, would something well understood and implemented like the dxf format would be a better start, or is it too old now (ie, without support for many things people are accustomed to)?
I remember playing Greed... along with a slew of other FPS between DOOM/DOOM II and Quake. And for a change, they had vastly different engines/gameplay/objectives!
Was it in that game that you had a camera pointing backwards, so you could see if something was happening behind your back? I'm pretty sure it was called the Asscam (no kidding).
If it wasn't in Greed, can somebody who recalls it can point me to the right game it was in?
The most infuriating thing is that fundamentally, they aren't that different from each other.
That's right. Their biggest difference is who's the publisher of the application. And it's also the reason why they're not very compatible with each other. Same thing in word processing: WordPerfect didn't have a filter to export to the latest Word format, now it's the other way around.
My field is Mechanical Engineering, and it has the same problem with CAD software. Each major player (Dassault, PTC, Autodesk, etc.) doesn't want you to be able to change your design application easily by having filters to export to other apps. And there are some "esperanto" formats, namely STEP and IGES.
The problems with these standard formats seems twofold. First, nobody ever tried to actually implement them completely. So an IGES file produced with CATIA might (or might not) be importable from Pro/E. So if it doesn't open, you're screwed, unless you can find some other format (or chain of formats) to go from program A to program B. Second, these standards are, in fact, not so standard themselves. There are a couple of ways to do most things in each of them, so a complete implementation would be monstruous. And I think there are some areas just left to the implementor.
Another thing to note is that even if you can get to the 3D geometry, it doesn't mean it will be modifiable. Of course you'll be able to add a hole or stuff like that, but if you say "Oh, this feature is not exactly what I want anymore, I need to modify this radius", you won't have access to the original feature because those two formats replace those higher level features by low level features (think at the level of lines and splines). Frankly, I'm not sure if they have indeed been intended for continuing design between applications, rather than just having access to the 3D geometry for further processing (think 5-axis milling).
But the thing is, it can be a desired feature of the format! That way, you can give away the final model, and not worry about possible modifications to it. Of course, it's not intended to allow you to change design application, just as 3DSMAX and Lightwave don't allow you to change easily...
Let's say I have a file with the following (meaningless) unsorted content:
asklhf
Adjgd
zaskd
Zaoifh
If I sort it with LC_ALL=posix sort myfile, here's what I get:
Adjgd
Zaoifh
asklhf
zaskd
Now, that is exactly the kind of behavior that you dislike.
Try this (LC_ALL=en_US sort myfile) now:
Adjgd
asklhf
Zaoifh
zaskd
Much like you wanted it to be, right? The C locale seems to give the same results as posix, and fr_CA gives the same thing as en_US. I'll leave it to somebody else to explain it by looking in a specific standard, or in the source code.
So in short, check that your locale is correctly specified, and sort should do what you want it to do. Or, you could just use the --ignore-case of sort.
Or were you talking about something system-wide, for ls, file selection boxes, etc.? Then it depends on where the sorting is done, and might be more difficult to fix (since you'll always miss one place).
For having used it (although only in CLI apps) a few years ago (1999-2000), I really really hated working with it. The compiler itself was Digital's, and it caused me and one of my colleagues quite a lot of problems.
For starters, the optimized version didn't run correctly, but would report that variables weren't declared (implicit declaration triggered a warning). So we had 3 versions: Debug, Release (optimized, but actually used for debugging), and Release-real (not optimized, but doing the right calculations).
Then, the linker had some problems once in a while, when it replaced the content of some object files/functions by memory filled with 0. Of course, when you ran into that code, the EIP register would, in time, point to some unallocated memory, and a SIGSEV (or whatever is the equivalent on Windows) would be sent. That problem was very visible in the debugger. The solution? Just recompile the whole thing, and you'd have something sane again. No source file needed to be modified. And I thought that compilers were deterministic...
Other than that, just make sure you know the language (especially when working with 20+ years old code): IF(CONDITION)10,20,30 is completely legal, as well as not declaring all your variables.
Back to my own experience, instead of making the GUI in Visual Fortran, it was a separate app in VB. I won't enter the details of what we needed to do to communicate between the two.
Another thing slows the spread of micros: the taxes per liter of beer. I believe (DISCLAIMER: I DO own 500 Unibroue stock) that the tax is higher for micros than for big breweries, so those can have a lower price because of that tax (I think it's something along 9 cents per liter for the big guys, to something around 28 cents per liter for the micros) in addition to scale economies.
IIRC, the rationale for the tax difference is that it's easier for the government to control the cleanliness, etc. of the big guys, than it is to control the smaller ones. The micros are trying to get that tax uniformised, but of course the big breweries lobby against it.
For Joe Sixpack, the price of his sixpack matters. If the micros' is a buck or two higher, there's a non negligible probability that he'll take the Coors Lite over the Blanche de Chambly, even though the latter won the Gold Medal of the Beverage Testing Institute of Chicago in 1997, 1998 and 1999.
I think it was some kind of bootrom plugged in the NICs. PXE something I think.
Anyway, it was emulating a floppy disk (replaced drive A) until it could load enough network drivers to boot Windows 95 off a remote HD. Since the content was (AFAIR) simple DOS drivers for the NIC and a bootstrap for Windows (config.sys and autoexec.bat mostly), I don't see why you couldn't boot other OSs with it. Of course, I don't have a product name so it might be difficult to find it.:(
Try the other way. It's faster when the pressure is higher. The more closer together the molecules, the easier it is for them to collide and spread the sound. The speed of sound in a solid is a couple times higher than in air.
If you're insterested: in perfect gases, v=(p*k/rho)^(1/2), with pressure p, k=Cp/Cv, and density rho.
So the speed of sound (Mach 1) at high altitude is way lower, in terms of absolute speed, than near the ground. Mach 1.68 at 25 miles is probably not even the same absolute speed (m/s) than Mach 1 at ground level. In a sufficiently rarified atmosphere (eg Mars), you might even be able to run faster than sound! How's that?
The merging of Patch A into the stable kernel would not affect Patch B or Patch C
They're not dependant on it, they're intermangled with it. They touch the same subsystems (same source files), although they can be orthogonal (in theory) to each other (applied in whatever combination you want). But still, you'll need to adapt each of those to the current kernel (and for each new kernel before your patch is adopted). That takes some efforts.
I agree that a very very very good revision system could maybe do the trick, although it'll need help from a (more likely, more than one) human.
Another thing is applications and libraries. Yes, normally they're independant from the kernel (to a certain point). But if your development and stable kernel are the same, you'll need to update some of those a lot more often if you upgrade your kernel. By contrast, a stable kernel series should be compatible with the same libs and apps from beginning to end. If there are some changes in API or new features, get the newer kernel series, along with updated apps and libs. It's called modularity. A new kernel series is effectively another module, even if it replaces a previous one and fulfils the same task.
Last thing (somewhat linked to the last point): up until now, I've mostly talked about the POV of a user (either server or desktop). Now I'll take the POV of a developer (distributor, or a company designing a new product using this technology). Field upgrades are a PITA. There are some ways to do them, but they're difficult (witness the number of unpatched IIS installation trying to propagate Code Red). When you need to do one, you (normally) prefer to change the minimum of things. So no jump from 2.0.32 to 2.4.19, but ideally 2.0.32 to 2.0.32+patches, or 2.0.40 if really needed. Now, if that 2.0.40 had diverged on a number of fronts from your 2.0.32, because features and major changes creep in in minor releases, your PITA has just grown again. It would be like basing your new product development on 2.5.0, and then trying to keep on top of new changes with every new releases. Good luck.
The problem I see with all those package repositeries (such as Debian's, RedCarpet, Gentoo portage's, freshrpms, autopackage's, etc.) is that you must wait for somebody to do the work of the packaging for you if you want to install something. Sure, it's more convenient when it's already done, but if I see something in source form (or even a binary tar.gz), I'd like to be able to install it correctly (ie, using my package manager) alone, possibly sharing the method used (spec file or equivalent) afterwards. Doing a RPM or a deb is actually quite easy for standard packages (the configure; make; make install kind of packages). But it could be even simpler. I'd put my efforts on that part of the packaging system.
Once you have an RPM or deb, the steps needed to actually install it are very easy (GnoRPM, cli rpm, RPMdrake, etc.). Limiting the source of the packages a user can install on their system by using said repositeries, even if they're comprehensive and large, is a counterproductive step IMHO. Because there will always be something newer (newer version of something already packaged, or just something not yet packaged) which you'll want.
More difficult to change big parts of the kernel, or entire subsystems, without a development kernel for which it is "normal" to be broken at times. For something in maintenance mode, the system you propose is quite fine (witness what's happening for 2.0, 2.2 and event 2.4 kernels). But for the bleeding edge, it's just not possible to do it that way, because patch A (which improves on the VM) affects patch B (VFS) and patch C (scheduler). So if you merge patch A (because it's deemed "stable") in the next official kernel release, then patch B and C must be reworked not beacuse of themselves, but because what they build upon has changed. Next, when patch C goes in, it's patch B's time to be adapted (again). It's more efficient to have all 3 develop at the same time in an unstable kernel, and have all the quirks sorted out. Of course, don't run those kernels on production machines...
The goal of the two kernel branches are different. One strives to be usable right now (bugfixes), the other one strives to be easier to work with in the future (more features, cleanup, performances ameliorations, etc.). If you merge those two together, you'll more than likely end up with something absolutely unstable, or a nightmare to manage (and merge different patches).
The goal of kernel development is not only to develop new features (aka advance). There's also a big part of it which goal is to keep running systems, well, running. It's for them that 2.0.40 is being prepared, as well as 2.2.22. And even 2.4.19 enters that category, which is quite different than the goal of 2.5.
As for the officiality of updates of older releases, it's only so that the development isn't split between a few groups with the same goals. I don't think a lot of the people currently working on the different subsystems of 2.5 also work a lot on 2.0.40, especially since the differences between the latest RCs are one or two fixes each time. OTOH, driver maintainers are more likely to follw it's development (although bugfixes only).
So in the end, it's not the double of the work to maintain (which implies "no new development", hence "not a huge workload") older kernels. And if nobody would need it, nobody would do it.
web browsers would default to https The problem lies in that to serve https requests, you need a certificate (logical). Now, if you want your certificate to actually identify you as who you really are, you need to be certified by a certificate authority (CA), which itself is certified by somebody else until a root certificate authority. The process of certification costs money, and doesn't take only a few minutes to complete. So in addition to the performance degradation due to the encrytion (not bad on a small server, but can grow quite fast), you'd be effectively limiting who can operate a web server. Or else, if the server's certificate doesn't go back to a root CA, you wouldn't have a certitude on the identity of the distant server.
As to how Unix handles the verification problem, the major distributors digitally sign (PGP usually) their packages with their (or one of their) private key. And what happens if the private key is compromised? Same thing as with any private key scheme: you're screwed.
For example, let's say that we're happy with the feature set in the 2.5 unstable series. Instead of putting off waiting for all of the bugs to get shaken out and call it 2.6, just switch from 2.5 to 2.7 on the unstable development side. Linus can pass the reins off to someone he trusts, we can have a GROF (Get Rid Of the Fin) party and his trusted lieutenant can finish stabilizing 2.5 into 2.6 without him.
The thing is, what needs to be done on the future 2.6 branch to stabilize it would also benefit 2.7. So the point of the current development model is to keep only one branch until it's really stable, then create the next development kernel branch on something which is sane. As a bonus you don't do the same work twice (stabilize the two branches for the same issues).
Now, if Linus is not the one you want in charge of this, he could always back-out of the last stabilizing efforts (IIRC, he doesn't particularly appreciate that part of development).
Branching before having a stable release would only cause both branches to diverge too much (especially in terms of bug fixes and drivers). And if you never have a "stable" development branch, it's kinda difficult to develop effectively on it. For example, see the current IDE situation in 2.5. To really develop on 2.5 atm, you need a SCSI machine because IDE seems too broken. Of course it will stabilize for 2.6, but if 2.7 is branched now, and then IDE is stabilized in 2.6, 2.7 won't necessarily have all the fixes (or some fixes won't make it to 2.6), if only because of communication problems.
So I think they'd better to work on 2.5 for now (obviously), then get into feature freeze, stabilize, release 2.6, wait a couple minor releases for it to be really stable (as in you'd be confortable using it on low-criticality (sp?) production machines after enough testing), and then start 2.7. Then 2.7 will start in a "known good" state.
The problem is, more than one entity can detain the same trademark in different juridictions, or even in the same juridiction if the markets are sufficiently different. Remember that small library called Amazon (sorry, don't recall in which state)? They were established before amazon.com, and tried to get the amazon.com domain, but obviously amazon.com is still the one we know.
So who do you give (or rather, sell) mtv.tm to? The MTV from the US, the MTV from Italy, or the MTV from Brazil? A generic homepage with a link to each and every such trademark registered, along with a small description of the company (location, market)? Actually, that's an idea. But then how do you order the links? More money gets you on top?
Maybe you remember a few years back, altavista.com wasn't the correct link for the search engine of the same name. The company operating altavista.com had a link on the top saying "The AltaVista search engine can be found here". After that they must have sold the domain, because altavista.com was the correct link for a couple years.
First impressions (from a 30 seconds try): no change. And reading the ChangeLog confirms it: only 1-2 bugfixes went in from 1.0.7 to 1.0.8. So it looks like it'll be as stable as the previous one was for me.
No problem here also. Evolution 1.0.7 on RH 7.3 (hand-compiled based on whatever SRPM which came with 7.3 originally). Mail only, I don't use the other features. It may be the accompanying libs. What's your gal, gtkhtml and bonobo-conf versions?
Just noticed that 1.0.8 was released yesterday, so I'll download it, compile it, try it and get back here.
Only things I dislike in 1.0.7 is that when I try to search the messages in a folder, sometimes it skips messages which I know contain the string. And when I Alt-tab to a message window, the keyboard focus is nowhere. I have to click before being able to type something.
He's not saying that you're paid $40/h. That's what a typical Slashdot reader costs to his employer (salary, rent for building, phone line, equipment, etc.). It's the amount of money the employer must pay in a year for employing an employee divided by the hours worked by the employee. It's probably used with regular time only, else it'll end up lower (more hours without the related rise in costs).
If there was a connector inside the PSU, you'd have been better to get a replacement fan. Power supply fans are usually plain 80mm 12V DC fans, although more and more also have a RPM sensor. While your fix may work for a couple months, a new fan would be good for a couple years.
In fact, even without any connectors, just replace the fan. Cut the wires and use any kind of connection to power the new fan (and no, electrical tape is not enough). That's what I did on the 1988 Phillips NMS-9000 of my parents a few years ago, and on my P-100 from 1995.
Of course, make sure the PSU is disconnected from the wall before opening it...
Slashdot Mirror
Laptop thieves don't care about your data. YOU care about your data.
Unless, like the article states, you're the US Army and you lost track of 600 laptops in the last years. Not every one of them contained highly sensitive info (well, I think), but it's still disturbing to know that somebody else can get access to the information which was on those.
If your data is important enough to you to warrant some kind of wrist gadget, it's probably important enough to somebody else who can try to get access to it by stealing your laptop for the info rather than for the hardware.
First thought I had: just remove the battery when you steal it, so that any gadget inside wouldn't be able to change something on the HDD. But the article says that the files are always encrypted, and only a cached copy (probably in RAM) is used when the user is viewing or modifying a file.
Time to find another loophole...
I'm not sure I really understand what you want to do. Let me explain.
Presently, you're a SysAdmin in a Web services company. And you want to change job, to get something less "commercial" and more "big picture", like Science/Research/Academia.
Are you aiming a SysAdmin job in that kind of environment (by opposition to where you are presently), or are you looking forward to do some science/research in a Academia environment? IE, is your target a teacher's or reasearcher's job, or a SysAdmin's job?
You're not asking about actual day to day job differences, just salary and job satisfaction, so I'm inclined to think that you want to remain a SysAdmin, but a confirmation from you could help us better answer your questions.
It's not much for the internal strings (function names, variables, etc.), more for the messages that the kernel can send to the user (or root). For the first kind of strings, you'd have to redefine the C standard, and change compiler (and maybe also change text editor).
When it boots, there's a whole slew of lines, many of which are purely numbers, but some of them could be localized (just as a big part of userland is). Now, since it would be in kernelspace, you'd maybe want to choose which one at compile time, but if you don't have access to a kind of Unicode for outputting strings, your choice of supported languages will be quite small.
Now, this doesn't go in the argument if it's a desired behavior or not, just that it's something necessary before outputting for any language.
Java has some reflexivity. Not as much as Smalltalk, but it has some. For instance, you can query an object class for about anything you want, but you cannot (easily) modify it runtime (add/modify a method).
For more info, check the java.lang.reflect.* documentation.
I'm not enough familiar with it to talk about it's meta-data capabilities.
And besides, usually you don't need that kind of functionnality, unless you're doing academic research on such languages, and then you'd probably use Scheme or Smalltalk anyway...
Thank you pmz for the specifics.
Then, would something well understood and implemented like the dxf format would be a better start, or is it too old now (ie, without support for many things people are accustomed to)?
I remember playing Greed... along with a slew of other FPS between DOOM/DOOM II and Quake. And for a change, they had vastly different engines/gameplay/objectives!
Was it in that game that you had a camera pointing backwards, so you could see if something was happening behind your back? I'm pretty sure it was called the Asscam (no kidding).
If it wasn't in Greed, can somebody who recalls it can point me to the right game it was in?
All Canadian diamonds have a tiny polar bear engraved on them. So you can know if it comes from up-north or down-south.
The most infuriating thing is that fundamentally, they aren't that different from each other.
That's right. Their biggest difference is who's the publisher of the application. And it's also the reason why they're not very compatible with each other. Same thing in word processing: WordPerfect didn't have a filter to export to the latest Word format, now it's the other way around.
My field is Mechanical Engineering, and it has the same problem with CAD software. Each major player (Dassault, PTC, Autodesk, etc.) doesn't want you to be able to change your design application easily by having filters to export to other apps. And there are some "esperanto" formats, namely STEP and IGES.
The problems with these standard formats seems twofold. First, nobody ever tried to actually implement them completely. So an IGES file produced with CATIA might (or might not) be importable from Pro/E. So if it doesn't open, you're screwed, unless you can find some other format (or chain of formats) to go from program A to program B. Second, these standards are, in fact, not so standard themselves. There are a couple of ways to do most things in each of them, so a complete implementation would be monstruous. And I think there are some areas just left to the implementor.
Another thing to note is that even if you can get to the 3D geometry, it doesn't mean it will be modifiable. Of course you'll be able to add a hole or stuff like that, but if you say "Oh, this feature is not exactly what I want anymore, I need to modify this radius", you won't have access to the original feature because those two formats replace those higher level features by low level features (think at the level of lines and splines). Frankly, I'm not sure if they have indeed been intended for continuing design between applications, rather than just having access to the 3D geometry for further processing (think 5-axis milling).
But the thing is, it can be a desired feature of the format! That way, you can give away the final model, and not worry about possible modifications to it. Of course, it's not intended to allow you to change design application, just as 3DSMAX and Lightwave don't allow you to change easily...
That behavior depends on your locale.
Let's say I have a file with the following (meaningless) unsorted content:
asklhf
Adjgd
zaskd
Zaoifh
If I sort it with LC_ALL=posix sort myfile, here's what I get:
Adjgd
Zaoifh
asklhf
zaskd
Now, that is exactly the kind of behavior that you dislike.
Try this (LC_ALL=en_US sort myfile) now:
Adjgd
asklhf
Zaoifh
zaskd
Much like you wanted it to be, right? The C locale seems to give the same results as posix, and fr_CA gives the same thing as en_US. I'll leave it to somebody else to explain it by looking in a specific standard, or in the source code.
So in short, check that your locale is correctly specified, and sort should do what you want it to do. Or, you could just use the --ignore-case of sort.
Or were you talking about something system-wide, for ls, file selection boxes, etc.? Then it depends on where the sorting is done, and might be more difficult to fix (since you'll always miss one place).
For having used it (although only in CLI apps) a few years ago (1999-2000), I really really hated working with it. The compiler itself was Digital's, and it caused me and one of my colleagues quite a lot of problems.
For starters, the optimized version didn't run correctly, but would report that variables weren't declared (implicit declaration triggered a warning). So we had 3 versions: Debug, Release (optimized, but actually used for debugging), and Release-real (not optimized, but doing the right calculations).
Then, the linker had some problems once in a while, when it replaced the content of some object files/functions by memory filled with 0. Of course, when you ran into that code, the EIP register would, in time, point to some unallocated memory, and a SIGSEV (or whatever is the equivalent on Windows) would be sent. That problem was very visible in the debugger. The solution? Just recompile the whole thing, and you'd have something sane again. No source file needed to be modified. And I thought that compilers were deterministic...
Other than that, just make sure you know the language (especially when working with 20+ years old code): IF(CONDITION)10,20,30 is completely legal, as well as not declaring all your variables.
Back to my own experience, instead of making the GUI in Visual Fortran, it was a separate app in VB. I won't enter the details of what we needed to do to communicate between the two.
That's easy: use GRUB or another "intelligent" boot loader, which doesn't need any editing to work.
Another thing slows the spread of micros: the taxes per liter of beer. I believe (DISCLAIMER: I DO own 500 Unibroue stock) that the tax is higher for micros than for big breweries, so those can have a lower price because of that tax (I think it's something along 9 cents per liter for the big guys, to something around 28 cents per liter for the micros) in addition to scale economies.
IIRC, the rationale for the tax difference is that it's easier for the government to control the cleanliness, etc. of the big guys, than it is to control the smaller ones. The micros are trying to get that tax uniformised, but of course the big breweries lobby against it.
For Joe Sixpack, the price of his sixpack matters. If the micros' is a buck or two higher, there's a non negligible probability that he'll take the Coors Lite over the Blanche de Chambly, even though the latter won the Gold Medal of the Beverage Testing Institute of Chicago in 1997, 1998 and 1999.
I think it was some kind of bootrom plugged in the NICs. PXE something I think.
:(
Anyway, it was emulating a floppy disk (replaced drive A) until it could load enough network drivers to boot Windows 95 off a remote HD. Since the content was (AFAIR) simple DOS drivers for the NIC and a bootstrap for Windows (config.sys and autoexec.bat mostly), I don't see why you couldn't boot other OSs with it. Of course, I don't have a product name so it might be difficult to find it.
Try the other way. It's faster when the pressure is higher. The more closer together the molecules, the easier it is for them to collide and spread the sound. The speed of sound in a solid is a couple times higher than in air.
If you're insterested: in perfect gases, v=(p*k/rho)^(1/2), with pressure p, k=Cp/Cv, and density rho.
So the speed of sound (Mach 1) at high altitude is way lower, in terms of absolute speed, than near the ground. Mach 1.68 at 25 miles is probably not even the same absolute speed (m/s) than Mach 1 at ground level. In a sufficiently rarified atmosphere (eg Mars), you might even be able to run faster than sound! How's that?
The merging of Patch A into the stable kernel would not affect Patch B or Patch C
They're not dependant on it, they're intermangled with it. They touch the same subsystems (same source files), although they can be orthogonal (in theory) to each other (applied in whatever combination you want). But still, you'll need to adapt each of those to the current kernel (and for each new kernel before your patch is adopted). That takes some efforts.
I agree that a very very very good revision system could maybe do the trick, although it'll need help from a (more likely, more than one) human.
Another thing is applications and libraries. Yes, normally they're independant from the kernel (to a certain point). But if your development and stable kernel are the same, you'll need to update some of those a lot more often if you upgrade your kernel. By contrast, a stable kernel series should be compatible with the same libs and apps from beginning to end. If there are some changes in API or new features, get the newer kernel series, along with updated apps and libs. It's called modularity. A new kernel series is effectively another module, even if it replaces a previous one and fulfils the same task.
Last thing (somewhat linked to the last point): up until now, I've mostly talked about the POV of a user (either server or desktop). Now I'll take the POV of a developer (distributor, or a company designing a new product using this technology). Field upgrades are a PITA. There are some ways to do them, but they're difficult (witness the number of unpatched IIS installation trying to propagate Code Red). When you need to do one, you (normally) prefer to change the minimum of things. So no jump from 2.0.32 to 2.4.19, but ideally 2.0.32 to 2.0.32+patches, or 2.0.40 if really needed. Now, if that 2.0.40 had diverged on a number of fronts from your 2.0.32, because features and major changes creep in in minor releases, your PITA has just grown again. It would be like basing your new product development on 2.5.0, and then trying to keep on top of new changes with every new releases. Good luck.
The problem I see with all those package repositeries (such as Debian's, RedCarpet, Gentoo portage's, freshrpms, autopackage's, etc.) is that you must wait for somebody to do the work of the packaging for you if you want to install something. Sure, it's more convenient when it's already done, but if I see something in source form (or even a binary tar.gz), I'd like to be able to install it correctly (ie, using my package manager) alone, possibly sharing the method used (spec file or equivalent) afterwards. Doing a RPM or a deb is actually quite easy for standard packages (the configure; make; make install kind of packages). But it could be even simpler. I'd put my efforts on that part of the packaging system.
Once you have an RPM or deb, the steps needed to actually install it are very easy (GnoRPM, cli rpm, RPMdrake, etc.). Limiting the source of the packages a user can install on their system by using said repositeries, even if they're comprehensive and large, is a counterproductive step IMHO. Because there will always be something newer (newer version of something already packaged, or just something not yet packaged) which you'll want.
- More difficult to change big parts of the kernel, or entire subsystems, without a development kernel for which it is "normal" to be broken at times. For something in maintenance mode, the system you propose is quite fine (witness what's happening for 2.0, 2.2 and event 2.4 kernels). But for the bleeding edge, it's just not possible to do it that way, because patch A (which improves on the VM) affects patch B (VFS) and patch C (scheduler). So if you merge patch A (because it's deemed "stable") in the next official kernel release, then patch B and C must be reworked not beacuse of themselves, but because what they build upon has changed. Next, when patch C goes in, it's patch B's time to be adapted (again). It's more efficient to have all 3 develop at the same time in an unstable kernel, and have all the quirks sorted out. Of course, don't run those kernels on production machines...
- The goal of the two kernel branches are different. One strives to be usable right now (bugfixes), the other one strives to be easier to work with in the future (more features, cleanup, performances ameliorations, etc.). If you merge those two together, you'll more than likely end up with something absolutely unstable, or a nightmare to manage (and merge different patches).
- The goal of kernel development is not only to develop new features (aka advance). There's also a big part of it which goal is to keep running systems, well, running. It's for them that 2.0.40 is being prepared, as well as 2.2.22. And even 2.4.19 enters that category, which is quite different than the goal of 2.5.
- As for the officiality of updates of older releases, it's only so that the development isn't split between a few groups with the same goals. I don't think a lot of the people currently working on the different subsystems of 2.5 also work a lot on 2.0.40, especially since the differences between the latest RCs are one or two fixes each time. OTOH, driver maintainers are more likely to follw it's development (although bugfixes only).
So in the end, it's not the double of the work to maintain (which implies "no new development", hence "not a huge workload") older kernels. And if nobody would need it, nobody would do it.web browsers would default to https
The problem lies in that to serve https requests, you need a certificate (logical). Now, if you want your certificate to actually identify you as who you really are, you need to be certified by a certificate authority (CA), which itself is certified by somebody else until a root certificate authority. The process of certification costs money, and doesn't take only a few minutes to complete. So in addition to the performance degradation due to the encrytion (not bad on a small server, but can grow quite fast), you'd be effectively limiting who can operate a web server. Or else, if the server's certificate doesn't go back to a root CA, you wouldn't have a certitude on the identity of the distant server.
As to how Unix handles the verification problem, the major distributors digitally sign (PGP usually) their packages with their (or one of their) private key. And what happens if the private key is compromised? Same thing as with any private key scheme: you're screwed.
For example, let's say that we're happy with the feature set in the 2.5 unstable series. Instead of putting off waiting for all of the bugs to get shaken out and call it 2.6, just switch from 2.5 to 2.7 on the unstable development side. Linus can pass the reins off to someone he trusts, we can have a GROF (Get Rid Of the Fin) party and his trusted lieutenant can finish stabilizing 2.5 into 2.6 without him.
The thing is, what needs to be done on the future 2.6 branch to stabilize it would also benefit 2.7. So the point of the current development model is to keep only one branch until it's really stable, then create the next development kernel branch on something which is sane. As a bonus you don't do the same work twice (stabilize the two branches for the same issues).
Now, if Linus is not the one you want in charge of this, he could always back-out of the last stabilizing efforts (IIRC, he doesn't particularly appreciate that part of development).
Branching before having a stable release would only cause both branches to diverge too much (especially in terms of bug fixes and drivers). And if you never have a "stable" development branch, it's kinda difficult to develop effectively on it. For example, see the current IDE situation in 2.5. To really develop on 2.5 atm, you need a SCSI machine because IDE seems too broken. Of course it will stabilize for 2.6, but if 2.7 is branched now, and then IDE is stabilized in 2.6, 2.7 won't necessarily have all the fixes (or some fixes won't make it to 2.6), if only because of communication problems.
So I think they'd better to work on 2.5 for now (obviously), then get into feature freeze, stabilize, release 2.6, wait a couple minor releases for it to be really stable (as in you'd be confortable using it on low-criticality (sp?) production machines after enough testing), and then start 2.7. Then 2.7 will start in a "known good" state.
The problem is, more than one entity can detain the same trademark in different juridictions, or even in the same juridiction if the markets are sufficiently different. Remember that small library called Amazon (sorry, don't recall in which state)? They were established before amazon.com, and tried to get the amazon.com domain, but obviously amazon.com is still the one we know.
So who do you give (or rather, sell) mtv.tm to? The MTV from the US, the MTV from Italy, or the MTV from Brazil? A generic homepage with a link to each and every such trademark registered, along with a small description of the company (location, market)? Actually, that's an idea. But then how do you order the links? More money gets you on top?
Maybe you remember a few years back, altavista.com wasn't the correct link for the search engine of the same name. The company operating altavista.com had a link on the top saying "The AltaVista search engine can be found here". After that they must have sold the domain, because altavista.com was the correct link for a couple years.
First impressions (from a 30 seconds try): no change. And reading the ChangeLog confirms it: only 1-2 bugfixes went in from 1.0.7 to 1.0.8. So it looks like it'll be as stable as the previous one was for me.
No problem here also. Evolution 1.0.7 on RH 7.3 (hand-compiled based on whatever SRPM which came with 7.3 originally). Mail only, I don't use the other features. It may be the accompanying libs. What's your gal, gtkhtml and bonobo-conf versions?
Just noticed that 1.0.8 was released yesterday, so I'll download it, compile it, try it and get back here.
Only things I dislike in 1.0.7 is that when I try to search the messages in a folder, sometimes it skips messages which I know contain the string. And when I Alt-tab to a message window, the keyboard focus is nowhere. I have to click before being able to type something.
He's not saying that you're paid $40/h. That's what a typical Slashdot reader costs to his employer (salary, rent for building, phone line, equipment, etc.). It's the amount of money the employer must pay in a year for employing an employee divided by the hours worked by the employee. It's probably used with regular time only, else it'll end up lower (more hours without the related rise in costs).
If there was a connector inside the PSU, you'd have been better to get a replacement fan. Power supply fans are usually plain 80mm 12V DC fans, although more and more also have a RPM sensor. While your fix may work for a couple months, a new fan would be good for a couple years.
In fact, even without any connectors, just replace the fan. Cut the wires and use any kind of connection to power the new fan (and no, electrical tape is not enough). That's what I did on the 1988 Phillips NMS-9000 of my parents a few years ago, and on my P-100 from 1995.
Of course, make sure the PSU is disconnected from the wall before opening it...