But it _isn't_ simple to make a safe way to delete files in/tmp which haven't been accessed in a while. If there were, all Unices would do it. About the only safe time to remove temp files is at boot, because you can't have malicious attackers manipulating/tmp.
I'd prefer to watch a DVD on my TV with surround (still stuck with prologic, but it's better than nothing), but when waiting for a delayed plane, or stuck on call late some weekend waiting for a long process to complete, it's nice to be able to fire up my laptop and watch a movie. After all, it's much more portable than my TV/stereo/DVD player at home.
The base of the vulnerability is that people include format strings in their locale database. This has been a recommended practice, because it would let you restructure messages when you localize the strings.
For example, you might have a message "Cannot open file %s". When translating the message to another language, the grammar of the language might require placing words after the file ("annotcay ilefay %s openway"). This is easy to do if you translate the whole format string, but if you'd constructed it by strcat("Cannot open file ", file) the translator can't reorder the message.
But this makes you vulnerable because attackers can specify the locale database they'd like to use, making the format string something absurd like "%s%s%s%s%s%s", smashing the stack and opening the door to exploits.
Unfortunately, I haven't seen anyone give an alternative. The original advisories just say "This is bad coding practice, don't do it" but don't offer any alternatives and point to documents which RECOMMEND DOING EXACTLY THIS.
So, a question to all... how to you write your code so that it's flexible enough for translation, but not open to attack?
If you do this, use NNTP or some sort of gateway. There are a plethora of offline readers for them, they are more featureful than just spewing the messages out over email or some web-specific client.
This will require that people learn to configure a newsreader, but those who are concerned about their online time are more often to have one already.
I don't believe that's entirely the case. You can download info from LOC with any Z39.51 client... I've done it. And I know that many libraries subscribe to their cataloging service and use their own OPACs.
But maybe the subscription service is the deal you're talking about....
I believe you can get all the authority tables from the LOC if you subscribe to their cataloging service... there's got to be a better way. FOIA, maybe?
Well, people are already working on the XML spec. (More than one, I think.) There is, I believe, a MARC XML spec based on the normal MARC format, but that's not the most user friendly format around. (It's designed to be converted back and forth to MARC.) I also think Dublin Core can be expressed in XML, but I'm not sure.
It wouldn't be easy. Real book cataloging doesn't fit very well into the vcard format (or most formats at all). Take a look at the MARC format at LOC for the format that real libraries use to interchange cataloging info.
If you build an app that uses that, and can use Z39.50, it can automatically seed your entries from detailed catalogs already available from your local library.
I got a bit of code put together to import, save and edit MARC records, with a minimal GTK app. I wasn't looking at perl at the time, because I'm not a perl hacker.
The major problem I ran into with writing something of the sort is that there's lots of information that you really want to have that isn't on the web. Cataloging rules, the full description of the MARC fields, some of the lists (organization, I think, is one example). I could get some of those from a library, but strangely enough although I'm sure most libraries have them, they aren't necessarily on the stacks, but in people's offices. Even then, I'd have to keep them checked out for long enough that I'd rather buy a copy.
But, if anyone wants to work on it I'd be glad to help. My ideal app would have to
Import records from the LOC or your Z39.50 server of your choice, given eithe ISBN or title
Keep track of holdings information, so I can keep track of books I've lent out, and where I'm keeping said book.
Handle magazine article references, so my wife can use it to manage her references in grad school. There's a way to store that stuff in MARC records, although it's not used very often.
Seems like a null-modem and a laptop (or another box) acting as a temporary serial console is the trick. I could have sworn RH had support for upgrades over a serial console, but I can't seem to find any info. Anyone know more?
Exactly. I keep a couple AOL freebie offers around just in case I have to go traveling and want a network to my machine. Having Linux will make it easier for me to suck my mail down from my home machine using an AOL preview cd.
Oh, yes. Suggesting that people who can't browse an FTP site (or get links mailed to them on the announce list) probably shouldn't watch their system being torn into shreds by a beta distribution is going to ruin Linux's chances in the real world.
So that's the reason my grandparents got Win2k betas?
Personally, I've never gotten any use out of 33.6 connections, let alone anything faster. One reason is the lack of modeming I've done for the last two years, but the other is that these connections seem to depend on absolutely ideal phone lines between you and your isp, and those are rare.
I think v.92 is just giving a bit more speed that few people will ever see, and I don't think it really matters.
Well, depends on the size of laptop you want. I have a Thinkpad A20p with about a 4 hour battery life. Better than my old Toshiba with a DSTN screen (3 hrs). That's because it has a much bigger battery.
Of course, my TP is about an inch wider and deeper, although it's actually thinner.
First, nobody in the Windows world is making money on hardware drivers. Especially not hardware vendors.
Second, closed source kernel drivers severely limit the user. You are limited to certain kernels, with certain options. You may not be able to apply security patches. And Linus has made it clear repeatedly that if the kernel needs to change and that breaks binary drivers, that's not his problem.
A hardware vendor providing binary only drivers relegates his hardware to second-class citizen status, because there are a lot of people who don't want to put on a straitjacket to use a certain piece of hardware.
I don't think it's bribery, so much as a lack of time and a desire not to scare companies away from the linux market.
Take, for example, WPO2000. Corel has done a lot of work to port lots of their software to Linux, and is one of the companies making it possible for more businesses to start using Linux on a desktop. I could see a well-meaning reviewer wishing to downplay problems found so as not to sully Corel's rep before they have a chance to fix things. Because otherwise, they might just abandon the platform entirely.
Also, a lot of the problems in WPO2k appear only for some people under some circumstances. Unless a reviewer happens to try that feature in the right circumstance, everything might work fine. This is a fault of any review: some things you just don't notice until you've used them in production for a while.
Slashdot Mirror
But it _isn't_ simple to make a safe way to delete files in /tmp which haven't been accessed in a while. If there were, all Unices would do it. About the only safe time to remove temp files is at boot, because you can't have malicious attackers manipulating /tmp.
That's not a problem. DVD players don't need to use the filesystem. OMS (livid) doesn't, and I have it working on 2.2.16.
You do need the DVD ioctls, but those have been in the last few 2.2 kernels.
I'd prefer to watch a DVD on my TV with surround (still stuck with prologic, but it's better than nothing), but when waiting for a delayed plane, or stuck on call late some weekend waiting for a long process to complete, it's nice to be able to fire up my laptop and watch a movie. After all, it's much more portable than my TV/stereo/DVD player at home.
When this last came up it was said that it had been released to OEMs, but nobody had found an oem to comment.
Looks like that's still the case.
The base of the vulnerability is that people include format strings in their locale database. This has been a recommended practice, because it would let you restructure messages when you localize the strings.
For example, you might have a message "Cannot open file %s". When translating the message to another language, the grammar of the language might require placing words after the file ("annotcay ilefay %s openway"). This is easy to do if you translate the whole format string, but if you'd constructed it by strcat("Cannot open file ", file) the translator can't reorder the message.
But this makes you vulnerable because attackers can specify the locale database they'd like to use, making the format string something absurd like "%s%s%s%s%s%s", smashing the stack and opening the door to exploits.
Unfortunately, I haven't seen anyone give an alternative. The original advisories just say "This is bad coding practice, don't do it" but don't offer any alternatives and point to documents which RECOMMEND DOING EXACTLY THIS.
So, a question to all... how to you write your code so that it's flexible enough for translation, but not open to attack?
If you do this, use NNTP or some sort of gateway. There are a plethora of offline readers for them, they are more featureful than just spewing the messages out over email or some web-specific client.
This will require that people learn to configure a newsreader, but those who are concerned about their online time are more often to have one already.
I don't believe that's entirely the case. You can download info from LOC with any Z39.51 client... I've done it. And I know that many libraries subscribe to their cataloging service and use their own OPACs.
But maybe the subscription service is the deal you're talking about....
I believe you can get all the authority tables from the LOC if you subscribe to their cataloging service... there's got to be a better way. FOIA, maybe?
if it can speak Z39.51, and just search the LOC for full entries based on ISBN. (Unfortunately, I don't know of such an OSS product.)
Well, people are already working on the XML spec. (More than one, I think.) There is, I believe, a MARC XML spec based on the normal MARC format, but that's not the most user friendly format around. (It's designed to be converted back and forth to MARC.) I also think Dublin Core can be expressed in XML, but I'm not sure.
It wouldn't be easy. Real book cataloging doesn't fit very well into the vcard format (or most formats at all). Take a look at the MARC format at LOC for the format that real libraries use to interchange cataloging info.
If you build an app that uses that, and can use Z39.50, it can automatically seed your entries from detailed catalogs already available from your local library.
The major problem I ran into with writing something of the sort is that there's lots of information that you really want to have that isn't on the web. Cataloging rules, the full description of the MARC fields, some of the lists (organization, I think, is one example). I could get some of those from a library, but strangely enough although I'm sure most libraries have them, they aren't necessarily on the stacks, but in people's offices. Even then, I'd have to keep them checked out for long enough that I'd rather buy a copy.
But, if anyone wants to work on it I'd be glad to help. My ideal app would have to
Seems like a null-modem and a laptop (or another box) acting as a temporary serial console is the trick. I could have sworn RH had support for upgrades over a serial console, but I can't seem to find any info. Anyone know more?
Exactly. I keep a couple AOL freebie offers around just in case I have to go traveling and want a network to my machine. Having Linux will make it easier for me to suck my mail down from my home machine using an AOL preview cd.
Interesting, but is that really the case? I just measured mine, and it has a 4x3 aspect ratio.
Unfortunately, the search plugin isn't present on all OSes (like Linux, last I checked).
Oh, yes. Suggesting that people who can't browse an FTP site (or get links mailed to them on the announce list) probably shouldn't watch their system being torn into shreds by a beta distribution is going to ruin Linux's chances in the real world.
So that's the reason my grandparents got Win2k betas?
Personally, I've never gotten any use out of 33.6 connections, let alone anything faster. One reason is the lack of modeming I've done for the last two years, but the other is that these connections seem to depend on absolutely ideal phone lines between you and your isp, and those are rare.
I think v.92 is just giving a bit more speed that few people will ever see, and I don't think it really matters.
Well, depends on the size of laptop you want. I have a Thinkpad A20p with about a 4 hour battery life. Better than my old Toshiba with a DSTN screen (3 hrs). That's because it has a much bigger battery.
Of course, my TP is about an inch wider and deeper, although it's actually thinner.
Actually, you want ediff-merge. emerge is a separate, older package and (imho) isn't as good.
(At least, on Emacs. I don't know if xemacs nuked emerge and replaced it with ediff.)
First, WSP says "Support all standards! Drop any development on the old codebase and work on the new codebase! We'll whine unless you don't."
Mozilla says "Look, that's going to take a long time. Are you sure you want to harangue us into doing it?"
WSP says yes.
Now, they're complaining that it's taking too long? They knew this coming in. It's like they want software to fall from the sky or something.
First, nobody in the Windows world is making money on hardware drivers. Especially not hardware vendors.
Second, closed source kernel drivers severely limit the user. You are limited to certain kernels, with certain options. You may not be able to apply security patches. And Linus has made it clear repeatedly that if the kernel needs to change and that breaks binary drivers, that's not his problem.
A hardware vendor providing binary only drivers relegates his hardware to second-class citizen status, because there are a lot of people who don't want to put on a straitjacket to use a certain piece of hardware.
I don't think it's bribery, so much as a lack of time and a desire not to scare companies away from the linux market.
Take, for example, WPO2000. Corel has done a lot of work to port lots of their software to Linux, and is one of the companies making it possible for more businesses to start using Linux on a desktop. I could see a well-meaning reviewer wishing to downplay problems found so as not to sully Corel's rep before they have a chance to fix things. Because otherwise, they might just abandon the platform entirely.
Also, a lot of the problems in WPO2k appear only for some people under some circumstances. Unless a reviewer happens to try that feature in the right circumstance, everything might work fine. This is a fault of any review: some things you just don't notice until you've used them in production for a while.
If I read CVS correctly, this has added support for at least some chips (such as the Rage Mobility 128).
So, what's with the 1x1 pixel bug on all slashdot pages?
s .pl,962470762278
http://209.207.224.245/Slashdot/pc.gif?/comment