"screw you, we'll ship with even less support for your product than we did before" dummy spits constitute "does not play nice with others" in my book.
This is not incompatible with 'a business-benefiting attitude' and 'acting in business-benefiting ways'. William Gates Jr has built a very successful business by acting exactly in this manner. If you think geeks have a bad attitude and businessmen do not, perhaps it's just because geeks publish their nastygram messages on the web and businesses keep them secret.
Trouble is, geeks carry no weight in business, and the businessfolks have all the money. It's up to us to decide if we want some of that money or not.
I think you have an incorrect assumption here. Theo de Raadt is not trying to get money. He is trying to improve a free operating system, OpenBSD.
I didn't say make the chips self-testing. Test them at the factory and write a defect list in a tiny EPROM or flash chip on the memory module. The only extra complexity is providing a way for the motherboard to query this information, but DIMMs already have presence detect for reporting their size and timings.
View the report and write it down on paper. Then include the BadRAM settings in the kernel parameters at boot time. Knoppix lets you type in kernel parameters if you press F1 or something just as it boots. You could later burn your own Knoppix CD, make a boot floppy, or whatever.
If it's just RAM, and the defects are just the odd bad location here and there, then BadRAM could help. The main difficulty is getting the support loaded early enough, e.g. at installation time. DIMMs could have their own defect list and a way for the motherboard to query it.
I guess one reason to use XML is that you can document your file format using a DTD or equivalent and then others can easily validate their documents against the DTD to check they are correct.
For koders I should have RTFM - you can search for most things, you just have to escape metacharacters with backslash. Perhaps it will be the thing to use; I just need to make sure all my own code is in there...
Yes - at first I thought this was going to be a search engine for source code, grepping through tons of free software. That would be a rather useful thing to have (how do I use this library? I'll just grep for an example). There is koders.com but its search engine isn't that gret - when looking through source code you need to be able to include punctuation characters and search by them.
All you really need to do is spider freshmeat.net, download the tarball of the latest release of each app, and do a massive grep whenever anyone submits a query. OK, not quite that simple. But almost - the total source code size is tiny compared to, say, a Web search engine, so you don't have to be that clever with indexing. You could do a keyword search as the first stage and then grep.
The Foveon X3 Capture chip requires a different kind of interpolation. Unlike CCD arrays, it captures three colors at every pixel location. But the colors are not well separated, so the raw data looks very gray. Enhancing the color without also enhancing noise is very difficult.
I don't know quite what dcraw's author means by this, but it seems to imply that even the Foveon chip isn't as good as a real R+G+B value at each pixel. Surely a lot better than capturing a black and white image then colorizing it, anyway:-p.
This technique might be seriously useful for digital cameras. Instead of a sensor with alternating RGB pixels, make one that is black and white. The B&W image will be somewhat sharper than a colour image made by interpolation (since you are getting the true brightness value at each pixel, not a guess based on that pixel and its neighbours), and the sensor will need much less light (instead of masking off all but red/green/blue light at each pixel, it gets the whole visible spectrum). It might also be cheaper to make.
Then add a really cheap and low-res colour image sensor and use that to colorize the B&W image. Or you could have a single sensor where most of the pixels detect white light, with occasional RGB clusters dotted around to get colours, and the 'scribble' algorithm used instead of conventional colour interpolation. Again, such a sensor could operate with less light than one where every pixel is R/G/B masked, so the camera could be built with cheaper optics (narrower lens aperture, etc). Although the colours (chrominance) in the final image would be less accurate than with a conventional sensor, the brightness (luminance) would be more accurate, and the eye is more sensitive to luminance than chrominance.
Final thought: could you use this for lossy image compression by storing the B&W image plus a few dots and scribbles to reconstruct the original? If you have plenty of time for compression you could keep trying or evolving different scribbles to get one giving acceptable results.
A couple of years ago I was using C for embedded systems, due to the fact that the overhead incurred by C++ was just too large.
Interesting... can you give some examples of the extra overhead? C++ advocates (including Stroustrup) usually claim that apart from the runtime support for exceptions, which can be turned off with many compilers, C++ has the same minimum overhead as C.
Where does CNET train its journalists?
on
GCC 4.0 Preview
·
· Score: 1
Amazing how a site like CNET can take an interesting story and mangle it to look like a regurgitated press release. Their authors must spend years honing this particular stilted style.
How about policy-driven application distribution? Triggered by the end user on demand instead of a push technology so you're not dumping unneeded garbage on every workstation?
I'd never considered 'unneeded garbage' to be a problem, certainly it appears less of a problem than the extra complexity involved in carefully measuring out the amount of garbage each machine gets. I'm referring to Linux systems here; on Windows it's not a good idea to install too many applications since they may do unpleasant things to your Registry or tread on each others' toes, but if you are just distributing RPM or deb packages there are few reasons not to solve the problem with 'install everything everywhere'.
Same with distributing printers, software patches, etc.
Printers: distribute out the/etc/printcap file with an overnight cron job (in the same manner as other system config files). Software patches: again rpm or dpkg handle this, when used with a management tool like apt or yum or smart.
(BTW, if you did for some reason want user-pull app installation on Linux, it's trivial to write a wrapper that lets the user run 'apt-get install gnumeric' or whatever. But I'd prefer to just put gnumeric on everyone's machine and be done with it.)
In this context, "configuration management" means managing OS versions, patches, software installation, upgrading and removal
I'd say apt or yum or smart or Red Carpet or (insert favourite package management tool here) handle these tasks pretty well. Perhaps Zenworks or other payware also do a good job but I don't see what real advantage it could have over the existing tools. On Windows, where every application has its own executable installer program, of course you need some kind of fancy tool to make things automatable. But on Linux we're lucky enough to have sane package management.
The only thing you can't smoothly do through the package manager is to upgrade to a whole new release of your distribution, unless you run Debian.
'hardware inventory management' sounds intriguing but I don't know what it is. For 'remote control', surely all Unix systems already have this?
at work, we have developers (a small minority of users), which get different software and permissions on their PC's than the rest of people
Again I can understand this on Windows but it makes less sense on Linux. Unless you're cursed with very small hard disks, you might as well just install all software on all hosts, since rpm or dpkg makes it easy to do so. And normally even a developer does not need any special access to the local machine - even if he or she did want to install additional software not available through package management, all Linux software can be built with './configure --prefix=$HOME' or equivalent.
When you refer to 'at work' are these Windows or Unix systems? I'm sure Zenworks is very useful for administering large numbers of Windows boxes, I'm just trying to get what it offers for those who live in the more civilized world of Unix.
I used to work (occasionally) in the Systems group at the department of Computing at Imperial College London. There were about five hundred desktops altogether of which most were dual-boot Linux/Windows with a few Linux-only. I don't doubt that many other universities have a similar setup. Certainly in CS departments but probably in others where Unix is common.
On Unix-like systems most of the policy is determined by config files in a user's home directory, which will be the same across all systems. Then there is a small amount of per-system configuration like X server configuration and who is allowed to log in, which can be done by distributing out config files to each host with an overnight cron job. What remains is configuring which software is installed, which is fairly easy to do by setting up a custom repository with yum/apt/smart/whatever.
I must be missing the point here - what is involved in managing desktops in a 'policy-driven fashion'? Perhaps it is more difficult if you can't assume that 99% of the desktop machines have almost identical settings.
To put things another way: hundreds of universities have big networks of Linux desktops, with a varied range of applications and hardware configurations. I don't think many of them shell out for expensive 'policy-driven' tools, yet they manage to enforce sensible policies in the face of fairly hostile and ingenious users (students). I understand the need for extra tools when administering Windows because Windows configuration is otherwise so fiddly and obscure. But I don't see what extra these tools bring to Unix.
I keep my mail in Unix mbox format. This is the format used natively by pine and many other Unix mail programs, but more importantly it's text-based and common enough that it'll never be indecipherable in the future.
Non-Unix mail programs often have the ability to export messages in a text format that is a bit like mbox but non-standard. I have written outlook_text_to_mbox to decode the text and CSV files written by MS Outlook.
I was thinking of working longer hours to earn more. This simple model doesn't always apply in the real world because many jobs are not paid by the hour.
This reminds me a little of Philip Greenspun's memo comparing software development to a Nazi concentration camp.
Nelson seems to be saying that if you're paid less, there is less incentive to give up leisure time for work. But the flaw in this argument is that if you have less money you need it more, so you may have to work harder and for longer simply _because_ you are paid less. This also applies to taxation: some argue that high income taxes hurt the economy by reducing the incentive to work, but others retort that if you tax the well-off harder, they will work more to compensate.
The main thing that worries me about this article's headline is that it may boost SCO's score on the operating system sucks-rules-o-meter. Ah, I see it's not included in the list. A narrow escape.
What about DOS Plus which (so I'm told) was some hybrid of DOS and CP-M/86? It was used on the Master 512 (think BBC Micro with 80186 board hanging off the second processor link) and other strange machines. One developer wrote PC software on the Master 512 under DOS Plus because 'if it runs there, it runs on anything!'. (I wonder if DR-DOS inherits any code from DOS Plus.)
Slashdot Mirror
Yes, yum is buggy and apt-get doesn't work with mixed 32/64 bit systems. Smart, however, is looking good - although currently still in development.
I don't know how well these three compare to urpmi. Does urpmi handle multiple installed versions of a package (eg, both 32 and 64 bit) correctly?
Will existing x86-64 Linux distributions Just Work on one of these processors?
I didn't say make the chips self-testing. Test them at the factory and write a defect list in a tiny EPROM or flash chip on the memory module. The only extra complexity is providing a way for the motherboard to query this information, but DIMMs already have presence detect for reporting their size and timings.
View the report and write it down on paper. Then include the BadRAM settings in the kernel parameters at boot time. Knoppix lets you type in kernel parameters if you press F1 or something just as it boots. You could later burn your own Knoppix CD, make a boot floppy, or whatever.
If it's just RAM, and the defects are just the odd bad location here and there, then BadRAM could help. The main difficulty is getting the support loaded early enough, e.g. at installation time. DIMMs could have their own defect list and a way for the motherboard to query it.
I guess one reason to use XML is that you can document your file format using a DTD or equivalent and then others can easily validate their documents against the DTD to check they are correct.
For koders I should have RTFM - you can search for most things, you just have to escape metacharacters with backslash. Perhaps it will be the thing to use; I just need to make sure all my own code is in there...
Yes - at first I thought this was going to be a search engine for source code, grepping through tons of free software. That would be a rather useful thing to have (how do I use this library? I'll just grep for an example). There is koders.com but its search engine isn't that gret - when looking through source code you need to be able to include punctuation characters and search by them.
All you really need to do is spider freshmeat.net, download the tarball of the latest release of each app, and do a massive grep whenever anyone submits a query. OK, not quite that simple. But almost - the total source code size is tiny compared to, say, a Web search engine, so you don't have to be that clever with indexing. You could do a keyword search as the first stage and then grep.
This technique might be seriously useful for digital cameras. Instead of a sensor with alternating RGB pixels, make one that is black and white. The B&W image will be somewhat sharper than a colour image made by interpolation (since you are getting the true brightness value at each pixel, not a guess based on that pixel and its neighbours), and the sensor will need much less light (instead of masking off all but red/green/blue light at each pixel, it gets the whole visible spectrum). It might also be cheaper to make.
Then add a really cheap and low-res colour image sensor and use that to colorize the B&W image. Or you could have a single sensor where most of the pixels detect white light, with occasional RGB clusters dotted around to get colours, and the 'scribble' algorithm used instead of conventional colour interpolation. Again, such a sensor could operate with less light than one where every pixel is R/G/B masked, so the camera could be built with cheaper optics (narrower lens aperture, etc). Although the colours (chrominance) in the final image would be less accurate than with a conventional sensor, the brightness (luminance) would be more accurate, and the eye is more sensitive to luminance than chrominance.
Final thought: could you use this for lossy image compression by storing the B&W image plus a few dots and scribbles to reconstruct the original? If you have plenty of time for compression you could keep trying or evolving different scribbles to get one giving acceptable results.
Amazing how a site like CNET can take an interesting story and mangle it to look like a regurgitated press release. Their authors must spend years honing this particular stilted style.
(BTW, if you did for some reason want user-pull app installation on Linux, it's trivial to write a wrapper that lets the user run 'apt-get install gnumeric' or whatever. But I'd prefer to just put gnumeric on everyone's machine and be done with it.)
I'd say apt or yum or smart or Red Carpet or (insert favourite package management tool here) handle these tasks pretty well. Perhaps Zenworks or other payware also do a good job but I don't see what real advantage it could have over the existing tools. On Windows, where every application has its own executable installer program, of course you need some kind of fancy tool to make things automatable. But on Linux we're lucky enough to have sane package management.
The only thing you can't smoothly do through the package manager is to upgrade to a whole new release of your distribution, unless you run Debian.
'hardware inventory management' sounds intriguing but I don't know what it is. For 'remote control', surely all Unix systems already have this?
Again I can understand this on Windows but it makes less sense on Linux. Unless you're cursed with very small hard disks, you might as well just install all software on all hosts, since rpm or dpkg makes it easy to do so. And normally even a developer does not need any special access to the local machine - even if he or she did want to install additional software not available through package management, all Linux software can be built with './configure --prefix=$HOME' or equivalent.
When you refer to 'at work' are these Windows or Unix systems? I'm sure Zenworks is very useful for administering large numbers of Windows boxes, I'm just trying to get what it offers for those who live in the more civilized world of Unix.
I used to work (occasionally) in the Systems group at the department of Computing at Imperial College London. There were about five hundred desktops altogether of which most were dual-boot Linux/Windows with a few Linux-only. I don't doubt that many other universities have a similar setup. Certainly in CS departments but probably in others where Unix is common.
I imagine Squeak would be a good language for demonstrating to children.
On Unix-like systems most of the policy is determined by config files in a user's home directory, which will be the same across all systems. Then there is a small amount of per-system configuration like X server configuration and who is allowed to log in, which can be done by distributing out config files to each host with an overnight cron job. What remains is configuring which software is installed, which is fairly easy to do by setting up a custom repository with yum/apt/smart/whatever.
I must be missing the point here - what is involved in managing desktops in a 'policy-driven fashion'? Perhaps it is more difficult if you can't assume that 99% of the desktop machines have almost identical settings.
To put things another way: hundreds of universities have big networks of Linux desktops, with a varied range of applications and hardware configurations. I don't think many of them shell out for expensive 'policy-driven' tools, yet they manage to enforce sensible policies in the face of fairly hostile and ingenious users (students). I understand the need for extra tools when administering Windows because Windows configuration is otherwise so fiddly and obscure. But I don't see what extra these tools bring to Unix.
I keep my mail in Unix mbox format. This is the format used natively by pine and many other Unix mail programs, but more importantly it's text-based and common enough that it'll never be indecipherable in the future.
Non-Unix mail programs often have the ability to export messages in a text format that is a bit like mbox but non-standard. I have written outlook_text_to_mbox to decode the text and CSV files written by MS Outlook.
A bit like this?
I was thinking of working longer hours to earn more. This simple model doesn't always apply in the real world because many jobs are not paid by the hour.
This reminds me a little of Philip Greenspun's memo comparing software development to a Nazi concentration camp.
Nelson seems to be saying that if you're paid less, there is less incentive to give up leisure time for work. But the flaw in this argument is that if you have less money you need it more, so you may have to work harder and for longer simply _because_ you are paid less. This also applies to taxation: some argue that high income taxes hurt the economy by reducing the incentive to work, but others retort that if you tax the well-off harder, they will work more to compensate.
The main thing that worries me about this article's headline is that it may boost SCO's score on the operating system sucks-rules-o-meter. Ah, I see it's not included in the list. A narrow escape.
Ruby on Rails - is this somehow related to The Little Engine That Could?
What about DOS Plus which (so I'm told) was some hybrid of DOS and CP-M/86? It was used on the Master 512 (think BBC Micro with 80186 board hanging off the second processor link) and other strange machines. One developer wrote PC software on the Master 512 under DOS Plus because 'if it runs there, it runs on anything!'. (I wonder if DR-DOS inherits any code from DOS Plus.)