Think about cryptosystems: The whole point about the really good ones is that you can know the algorithm, but still not break it. Granted, pulling that off for a search engine is prone to be much, much harder -- but I *do* believe it's well within the realm of possibility. Ambitious in the extreme? Certainly... but there's something to be said for high-risk-high-reward projects.
Product schoduct! The cartoon-like picture of tux with a hard hat on--now there was something neat!
Yup, I thought so too.
And then the damn head marketing weenie (whom we hired from *SCO* of all places... think big red horns on her head, and that was long before this current fiasco) made us change the product name and kill the audio tracks from our distro CDs and started promising customers products we didn't have finished yet... ahh, well.
I still haven't met as generally kick-ass an engineering team since, tho.
Re:Multiple FireWire cameras under Linux?
on
Linux Hits the Road
·
· Score: 1
I'm amazed they got that to work. The FireWire hot-plugging support in Linux is a mess, doesn't handle the hard cases, and needs a complete redesign. Camera support is ugly, with a wierd interface between the application and the driver.
Just curious, when was this?
I'm not heavily involved with Linux firewire, but I've been tracking it vaguely, and I understand that they've actually got a proper solution for the hotplug thing that works against 2.5 (and presumably, now, 2.6).
Now, I'm not *using* 2.5 or newer, and haven't looked at this code myself, so I have no firsthand knowledge here... it's just something I think I recall seeing mentioned in the mailing list archives within the last few months.
Ya know, comparing QNX to HURD is *far* too nice to the HURD.
Yes, they're both microkernels -- but one is small and fast, and one is huge and slow. If you want a small and fast and well-designed microkernel OS (who some embedded systems development types I know have been putting some serious time into), try taking a look at VSTa.
FWIW, I used to work at MontaVista. I'm still kind of fond of the product we made. For smaller projects I'd be thinking *reeeal* hard about using VSTa instead (yes, I'd prolly have to write a fair bit of the hardware support myself -- but it'd still have a dramatically lower footprint and, on account of being in userspace, those drivers would actually be easy to debug), but for bigger projects (say, anything involving a serious GUI subsystem) I'd prolly try to get my employer to shell out for a copy of MV{L,G} or QNX or somesuch.
Plus, I hate stores that make you "clear customs" before you can leave.
They can't legally enforce that without good reason to think you're stealing something -- otherwise, they can be legally sued for false arrest by detaining you as you walk out the door.
It's really happened, too (at least in Texas).
This isn't the case for places like Costco because agreeing to let them look through your purchases is in the agreement you sign when becoming a member.
FreeBSD I'd believe, OpenBSD maybe. NetBSD... god, man, have you *seen* their kernel tree?
Ugliest POS I've ever seen, full of (mostly half-functional) separate "ports" targeting the same #!@$ set of architectures! If the NetBSD folks counted architectures sanely (read: one port per architecture, the same way Linux and folks do) and only included ports that actually had a sanely working userland (once again, the way Linux and folks do), they'd be well *behind* much of the rest of the world in terms of portability.
Re:What does this have to do with ohm's law?
on
More on Spintronics
·
· Score: 1
Ahh, but look: if they're knowingly and willfully violating the license, they're exactly the sort of users we'd rather *not* have. OTOH, if they start obeying the license, then they become the kind of user we *would* like to have. Works out fine either way!
The bad news is that they are violating the gpl.:( I even submitted a/. article that is still pending after 2 days trying to deal with this. I need to recompile the kernel on one of the units I bought from them, but they won't release the kernel sources to me. *sigh*
Have any code in the kernel? Have any friends that do? (One of my roommates does, but he's busy enough as it is).
All you need is a kernel contributer whose code they're failing to redistribute to send them a warning and (if they don't respond) file a lawsuit against them. Ask for an injunction against their distribution of the infringing product, and they'll settle (presuming you ask something reasonable... say, the court costs you've incurred + release of the source) right quick.
So... you download it from somewhere the developer wanted to redistribute it to the general public via, then you've got a legal copy -- but it's still not clear for redistribution without the developer's permission, granted via the GPL if you agree to its terms.
See I am not so sure about this still. Because if the GPL goes away then everything falls back to default copyright law. Doesn't that then mean you have an illegal copy of Linux because without the GPL the developers have given no one permission to copy it? Sort of like downloading warez, MP3, copying CDs...
Ahh, but here's the thing: The developer can give you a copy under copyright law if they wish to -- and if you have a copy of an open source program that you got with the developer's blessing (from their web site, or from sourceforge or something where the developer willingly put it there to be downloaded by the public), then that copy was made with the developer's permission and it's clean. The only sticky thing is redistribution rights -- even if the developer gives you a copy (hands you a CD personally, say) that doesn't automatically grant you redistribution rights unless the developer *says* you can redistribute it -- which is what developers who use the GPL are doing, albeit with some restrictions. So... you download it from somewhere the developer wanted to redistribute it to the general public via, and you've got a legal copy -- but it's still not clear for redistribution without the developer's permission, granted via the GPL if you agree to its terms.
Ah, ah, ah! But the GPL isn't a *use* license, it's a *redistribution* license. The developers gave it to you to use for free, with all the rights that copyright law doesn't prohibit; they then additionally offered you a chance to redistribute it if you comply with the GPL.
If the GPL goes away, you still have the free ability to use the software -- but no ability to redistribute the product or create derivative works.
Even if the GPL is deemed unenforcable - and it reverts to sort of a BSD license, it still think Free Software will win in the long run.
If the GPL is invalid, I'm not sure that's what it *would* revert to. Of course, it depends heavily on which clauses are found to be unenforcable -- if the whole license were to just go away, then the end result for users is standard copyright law -- which is to say, no license to redistribute at all.
I think. But then, I only took a few semesters of law (and most certainly am not a lawyer), so I could be full of it.
There will be a wider range of skills and expertise in a larger company simply because there are more employees. For example, I am basically the UNIX expert in my current company because I am the only one with any experience (not because I am anything close to a guru), so when there is a UNIX problem I do not know how to fix, I have no one in house that can help me. Thank God for the Internet!
That's not always true. When I worked at MontaVista Software (about 30 people when I started as an intern, about 120 when I left), one of my favorite aspects of the place was that the engineering department was almost entirely made up of individuals who were dedicated, talented, experienced, helpful, and otherwise very, very good. My coworkers included core kernel coders (particularly PPC and MIPS folks), a GCC maintainer, and the best engineering manager I've ever had the privilege to work under.
For any question I had -- whether it was in regard to hardware-level kernel debugging or filesystem design or clustered computing -- someone there could be found who was expert in that field.
I'm sure that, as a general rule, large companies may have a greater pool of expertise -- but I can't imagine a better place to learn than a small, tight-knit company with an engineering staff of exceptional skill.
Still depends where 'yer at. My last few jobs have been at startups, and neither has had a dress code of any sort (except for sales and other customer-facing staff); the one before that was at a car dealership, and while everyone *else* had a dress code, I (as the 1-man IT staff and maintainer of the huge, crufty old codebase for the app that ran their company) was effectively exempt. I understand some larger companies to be becoming a bit more lax also.
So... don't give up on yer ponytail -- it may survive your professional employment after all.
FWIW, a few things you could consider looking into:
- Are your X drivers well-supported and stable? Traditionally, this is the largest source of stability issues on Linux, though it's been less of a problem over the past few years. Consider using the framebuffer interface [presuming your card is VESA compatible or has framebuffer support, of course] if you suspect this an issue -- yes, you'll lose some speed, if it's handled right you'll also eliminate your X server's ability to access hardware directly, and hence it's ability to crash the machine.
- Is your hardware flaky? Run memtest86 and like tools. Different operating systems tend to stress different parts of the hardware, so you can have hardware problems that cause crashes frequently on one OS and rarely if at all on another. In my experience, this right here is perhaps the leading cause of system instability on Linux systems, particularly as XFree86 has been stabilizing.
There are the occasional other drivers that are a little questionable (if yer running your primary drive off firewire, for instance, I'd look in that direction) -- but hopefully one of the items I mentioned above will help you resolve your stability issues on Linux.
The greatest coders in the world still have bugs in their code
Maybe a few -- very, very few. At last report, TeX (by Donald Knuth) -- an exceedingly complex piece of software -- has at last report had no bugs found since '94 or '95.
It's Microsoft's fault for making a system where *having* too many screen savers or font packs or useless little running applications can impact the stability. Good operating system design implies a separation between application and system-level processes, and between the applications themselves; having applications that can take down the system implies that this separation isn't well enforced.
Likewise, having too many apps that load VxDs or other code that runs with OS-level privileges implies that the OS isn't well-enough designed to let the necessary functions be done with code having only regular user priveleges.
It's a cliche, but in today's market it's not what you know, but who you know.
I can agree with that. The startup I work for is starved for qualified coders -- but half of what we seem to hire these days are people with unremarkable skills who are old friends with our VP of Engineering. He'll personally vouch for the qualifications of each and every one of them, though.
The initial claims of almost any patent are *expected* to be thrown out; the line between the valid and invalid ones (if any are indeed valid and enforceable) is one of those things that gets decided in court.
I do agree, however, that the practice of including claims that are obviously invalid (even to someone unfamiliar with the technology) is inherently broken, and should probably be grounds for refusal of a patent application.
Simply put: If SVN does what you need, you don't expect enough from your version control tool.
I *have* had crashes (of the client, that is), though no corruption -- but SVN has too much code for the functionality it provides (and is correspondingly hard to implement -- while arch has had numerous 3rd-party reimplementations). Worse, SVN is missing features that other late-model revision control systems have, and (here's the most important one) doesn't have the ability to add those features without a major redesign. Look at some of the history-sensitive automatic merge operations being included in new RCSs today and you'll see what I mean.
The reliability issues with subversion are not so much repository corruption issues as program failures -- I've had it crash on me or refuse to touch my working copy more times than I'd like to admit. In any event, however, the design issues are larger ones; see Lord's analysis on arch-users for that -- to make a strong argument I'd be simply parroting his arguments.
darcs has a very nifty merge algorithm -- but it's not practical for immediate use, and not nearly so actively maintained as arch, which has a substantial active user base, constant maintenance, a nontrivial suite of 3rd-party tools available (see cscvs for converting CVS archives to arch or tla format, perspective for a nifty web-based repository viewer, and assorted other stuff as well); further, in its tla incarnation, arch is far faster. I wish darcs well, and hope to see its merge algorithm integrated into arch (and indeed, I understand that Tom is doing some work to make those pluggable, and I understand that Robert Collins may end up working on some new ones taking advantage of said pluggability) -- but don't see it as much as a serious revision control tool as a very nifty proof-of-concept of a damn cool merging algorithm.
Slashdot Mirror
Think about cryptosystems: The whole point about the really good ones is that you can know the algorithm, but still not break it. Granted, pulling that off for a search engine is prone to be much, much harder -- but I *do* believe it's well within the realm of possibility. Ambitious in the extreme? Certainly... but there's something to be said for high-risk-high-reward projects.
Product schoduct! The cartoon-like picture of tux with a hard hat on--now there was something neat!
Yup, I thought so too.
And then the damn head marketing weenie (whom we hired from *SCO* of all places... think big red horns on her head, and that was long before this current fiasco) made us change the product name and kill the audio tracks from our distro CDs and started promising customers products we didn't have finished yet... ahh, well.
I still haven't met as generally kick-ass an engineering team since, tho.
I'm amazed they got that to work. The FireWire hot-plugging support in Linux is a mess, doesn't handle the hard cases, and needs a complete redesign. Camera support is ugly, with a wierd interface between the application and the driver.
Just curious, when was this?
I'm not heavily involved with Linux firewire, but I've been tracking it vaguely, and I understand that they've actually got a proper solution for the hotplug thing that works against 2.5 (and presumably, now, 2.6).
Now, I'm not *using* 2.5 or newer, and haven't looked at this code myself, so I have no firsthand knowledge here... it's just something I think I recall seeing mentioned in the mailing list archives within the last few months.
Ya know, comparing QNX to HURD is *far* too nice to the HURD.
Yes, they're both microkernels -- but one is small and fast, and one is huge and slow. If you want a small and fast and well-designed microkernel OS (who some embedded systems development types I know have been putting some serious time into), try taking a look at VSTa.
FWIW, I used to work at MontaVista. I'm still kind of fond of the product we made. For smaller projects I'd be thinking *reeeal* hard about using VSTa instead (yes, I'd prolly have to write a fair bit of the hardware support myself -- but it'd still have a dramatically lower footprint and, on account of being in userspace, those drivers would actually be easy to debug), but for bigger projects (say, anything involving a serious GUI subsystem) I'd prolly try to get my employer to shell out for a copy of MV{L,G} or QNX or somesuch.
Plus, I hate stores that make you "clear customs" before you can leave.
They can't legally enforce that without good reason to think you're stealing something -- otherwise, they can be legally sued for false arrest by detaining you as you walk out the door.
It's really happened, too (at least in Texas).
This isn't the case for places like Costco because agreeing to let them look through your purchases is in the agreement you sign when becoming a member.
FreeBSD I'd believe, OpenBSD maybe. NetBSD... god, man, have you *seen* their kernel tree?
Ugliest POS I've ever seen, full of (mostly half-functional) separate "ports" targeting the same #!@$ set of architectures! If the NetBSD folks counted architectures sanely (read: one port per architecture, the same way Linux and folks do) and only included ports that actually had a sanely working userland (once again, the way Linux and folks do), they'd be well *behind* much of the rest of the world in terms of portability.
Well, I would presume...
ohm's law:electronics::his replacement:spintronics
(Read that as: "Ohm's law is to electronics as his replacement is to spintronics").
Ahh, but look: if they're knowingly and willfully violating the license, they're exactly the sort of users we'd rather *not* have. OTOH, if they start obeying the license, then they become the kind of user we *would* like to have. Works out fine either way!
(Yes, I feed the trolls).
The bad news is that they are violating the gpl. :( I even submitted a /. article that is still pending after 2 days trying to deal with this. I need to recompile the kernel on one of the units I bought from them, but they won't release the kernel sources to me. *sigh*
Have any code in the kernel? Have any friends that do? (One of my roommates does, but he's busy enough as it is).
All you need is a kernel contributer whose code they're failing to redistribute to send them a warning and (if they don't respond) file a lawsuit against them. Ask for an injunction against their distribution of the infringing product, and they'll settle (presuming you ask something reasonable... say, the court costs you've incurred + release of the source) right quick.
that is to say:
So... you download it from somewhere the developer wanted to redistribute it to the general public via, then you've got a legal copy -- but it's still not clear for redistribution without the developer's permission, granted via the GPL if you agree to its terms.
See I am not so sure about this still. Because if the GPL goes away then everything falls back to default copyright law. Doesn't that then mean you have an illegal copy of Linux because without the GPL the developers have given no one permission to copy it? Sort of like downloading warez, MP3, copying CDs...
Ahh, but here's the thing: The developer can give you a copy under copyright law if they wish to -- and if you have a copy of an open source program that you got with the developer's blessing (from their web site, or from sourceforge or something where the developer willingly put it there to be downloaded by the public), then that copy was made with the developer's permission and it's clean. The only sticky thing is redistribution rights -- even if the developer gives you a copy (hands you a CD personally, say) that doesn't automatically grant you redistribution rights unless the developer *says* you can redistribute it -- which is what developers who use the GPL are doing, albeit with some restrictions. So... you download it from somewhere the developer wanted to redistribute it to the general public via, and you've got a legal copy -- but it's still not clear for redistribution without the developer's permission, granted via the GPL if you agree to its terms.
Ah, ah, ah! But the GPL isn't a *use* license, it's a *redistribution* license. The developers gave it to you to use for free, with all the rights that copyright law doesn't prohibit; they then additionally offered you a chance to redistribute it if you comply with the GPL.
If the GPL goes away, you still have the free ability to use the software -- but no ability to redistribute the product or create derivative works.
Even if the GPL is deemed unenforcable - and it reverts to sort of a BSD license, it still think Free Software will win in the long run.
If the GPL is invalid, I'm not sure that's what it *would* revert to. Of course, it depends heavily on which clauses are found to be unenforcable -- if the whole license were to just go away, then the end result for users is standard copyright law -- which is to say, no license to redistribute at all.
I think. But then, I only took a few semesters of law (and most certainly am not a lawyer), so I could be full of it.
There will be a wider range of skills and expertise in a larger company simply because there are more employees. For example, I am basically the UNIX expert in my current company because I am the only one with any experience (not because I am anything close to a guru), so when there is a UNIX problem I do not know how to fix, I have no one in house that can help me. Thank God for the Internet!
That's not always true. When I worked at MontaVista Software (about 30 people when I started as an intern, about 120 when I left), one of my favorite aspects of the place was that the engineering department was almost entirely made up of individuals who were dedicated, talented, experienced, helpful, and otherwise very, very good. My coworkers included core kernel coders (particularly PPC and MIPS folks), a GCC maintainer, and the best engineering manager I've ever had the privilege to work under.
For any question I had -- whether it was in regard to hardware-level kernel debugging or filesystem design or clustered computing -- someone there could be found who was expert in that field.
I'm sure that, as a general rule, large companies may have a greater pool of expertise -- but I can't imagine a better place to learn than a small, tight-knit company with an engineering staff of exceptional skill.
Still depends where 'yer at. My last few jobs have been at startups, and neither has had a dress code of any sort (except for sales and other customer-facing staff); the one before that was at a car dealership, and while everyone *else* had a dress code, I (as the 1-man IT staff and maintainer of the huge, crufty old codebase for the app that ran their company) was effectively exempt. I understand some larger companies to be becoming a bit more lax also.
So... don't give up on yer ponytail -- it may survive your professional employment after all.
Heh, quite so.
FWIW, a few things you could consider looking into:
- Are your X drivers well-supported and stable? Traditionally, this is the largest source of stability issues on Linux, though it's been less of a problem over the past few years. Consider using the framebuffer interface [presuming your card is VESA compatible or has framebuffer support, of course] if you suspect this an issue -- yes, you'll lose some speed, if it's handled right you'll also eliminate your X server's ability to access hardware directly, and hence it's ability to crash the machine.
- Is your hardware flaky? Run memtest86 and like tools. Different operating systems tend to stress different parts of the hardware, so you can have hardware problems that cause crashes frequently on one OS and rarely if at all on another. In my experience, this right here is perhaps the leading cause of system instability on Linux systems, particularly as XFree86 has been stabilizing.
There are the occasional other drivers that are a little questionable (if yer running your primary drive off firewire, for instance, I'd look in that direction) -- but hopefully one of the items I mentioned above will help you resolve your stability issues on Linux.
Good luck!
The greatest coders in the world still have bugs in their code
Maybe a few -- very, very few. At last report, TeX (by Donald Knuth) -- an exceedingly complex piece of software -- has at last report had no bugs found since '94 or '95.
It's Microsoft's fault for making a system where *having* too many screen savers or font packs or useless little running applications can impact the stability. Good operating system design implies a separation between application and system-level processes, and between the applications themselves; having applications that can take down the system implies that this separation isn't well enforced.
Likewise, having too many apps that load VxDs or other code that runs with OS-level privileges implies that the OS isn't well-enough designed to let the necessary functions be done with code having only regular user priveleges.
It's a cliche, but in today's market it's not what you know, but who you know.
I can agree with that. The startup I work for is starved for qualified coders -- but half of what we seem to hire these days are people with unremarkable skills who are old friends with our VP of Engineering. He'll personally vouch for the qualifications of each and every one of them, though.
*sigh*.
The initial claims of almost any patent are *expected* to be thrown out; the line between the valid and invalid ones (if any are indeed valid and enforceable) is one of those things that gets decided in court.
I do agree, however, that the practice of including claims that are obviously invalid (even to someone unfamiliar with the technology) is inherently broken, and should probably be grounds for refusal of a patent application.
Simply put: If SVN does what you need, you don't expect enough from your version control tool.
I *have* had crashes (of the client, that is), though no corruption -- but SVN has too much code for the functionality it provides (and is correspondingly hard to implement -- while arch has had numerous 3rd-party reimplementations). Worse, SVN is missing features that other late-model revision control systems have, and (here's the most important one) doesn't have the ability to add those features without a major redesign. Look at some of the history-sensitive automatic merge operations being included in new RCSs today and you'll see what I mean.
Happy now?
http://lists.fifthvision.net/pipermail/arch-users/ 2003-February/025283.html
Oooh, I didn't read that far. Yup, that's waaaay outta line.
The reliability issues with subversion are not so much repository corruption issues as program failures -- I've had it crash on me or refuse to touch my working copy more times than I'd like to admit. In any event, however, the design issues are larger ones; see Lord's analysis on arch-users for that -- to make a strong argument I'd be simply parroting his arguments.
darcs has a very nifty merge algorithm -- but it's not practical for immediate use, and not nearly so actively maintained as arch, which has a substantial active user base, constant maintenance, a nontrivial suite of 3rd-party tools available (see cscvs for converting CVS archives to arch or tla format, perspective for a nifty web-based repository viewer, and assorted other stuff as well); further, in its tla incarnation, arch is far faster. I wish darcs well, and hope to see its merge algorithm integrated into arch (and indeed, I understand that Tom is doing some work to make those pluggable, and I understand that Robert Collins may end up working on some new ones taking advantage of said pluggability) -- but don't see it as much as a serious revision control tool as a very nifty proof-of-concept of a damn cool merging algorithm.
Pardon? I don't recall the RIAA blacklisting anyone's mail hosts, and don't see vhy I'd be too upset if they did.