Slashdot Mirror


User: spitzak

spitzak's activity in the archive.

Stories
0
Comments
5,741
First seen
Last seen
Profile
(view on slashdot.org)

Comments · 5,741

  1. Re:are the recordings encrypted ? on Cable Boxes With DVD, MP3, Networking · · Score: 1
    I would expect so, unless they are incredibly stupid.

    Other possibilities that would probably be almost as stupid: the disk is not ext3 or any other known format (that will stop people for about 10 seconds), or the disk hardware is designed so that it cannot be disconnected from the box or accessed without wrecking it.

  2. Re:WinXP filesystem strangeness on State Of The Filesystem · · Score: 1
    Never mind, it appears that my Win2k box works the same as Linux. Creating, renaming, and deleting files changes the date modified. However writing new data to an existing file does not change the modified date, and I believe we are being fooled by different behaviors of the linker, on Unix it deletes the file and creates a new one, on Windows it just writes over an existing one. This also means I can fix it by making the make delete the old file before creating the new one!

    Sorry, don't have XP here to check out.

  3. Re:Transferring Files on State Of The Filesystem · · Score: 1
    Yes, but the work would not be done by the "file format" but by user-level plugins that translate attempts to access "foo.mp3/blah" into the value of "blah" stored in the file. Also because it is slow, file-system support for "metadata" would be very nice, because such a program can then store the result into the metadata "blah" so it can be accessed instantly next time. However if you then copy the mp3 file to another disk and ask for blah, rather than the requiring copying of the metadata, instead the same program would run and extract the information.

    And it would certainly be better to have one program for each of these MP3 types than to have every program that wants to catalog files in any way have to understand every MP3 file format.

    True text/plain files, where every single byte is not a comment, will only be able to have metadata if it is stored seperately, and thus such metadata will only work on filesystems that support it, and reading "file/" will have to produce some cooked version that contains the metadata so it can be copied to another disk. However I am unaware of any text format that does not support comments. Have you taken a look at any code checked into CVS or edited with Emacs? Putting metadata into comments is an already well-established practice.

  4. Re:Caught My Attention on Torvalds Says Linux IP Is Sound · · Score: 1
    There might be a "need" for the GPL if there were no copyrights, but the GPL as written would be meaningless if there were no copyrights.

    Without copyrights everything would be in the public domain. Despite what Microsoft feverishly wants people to believe, the GPL is not a signed contract and in no way can it cause you to give up any rights you already have. If there was no copyright laws you would have the right to copy anything, and you could therefore copy the GPL code any way you want.

  5. Re:Maybe I'm just being picky on State Of The Filesystem · · Score: 1

    Um, he's saying that GConf is bad and that his ideas would remove the need for GConf (and the Windows Registry is not just the "same catagory", but actually the same thing as GConf as far as this is concerned).

  6. Re:WinXP filesystem strangeness on State Of The Filesystem · · Score: 1

    Win2k and NT both worked the same as you are seeing. It breaks our gmake scripts that use directories to check if any files inside them have changed, so I am familiar with this, and it has been doing it for as long as I can remember.

  7. Re:common ENV variables... on State Of The Filesystem · · Score: 1

    The paper described the Plan9 system where each process has it's own namespace. So you just fork a process that changes it's namespace to whatever is necessary before running the program. Similar to forking and changing the environment on Unix now.

  8. Re:Questions... on State Of The Filesystem · · Score: 1
    Absolutly exactly what you suggest should be supported.

    The idea may be clearer if you think of the metadata as a "cache" of data extracted from the file. In the ideal situation deleting all the metadata would just make extracting it a bit slower, but you would get it all back.

  9. Re:Incompatibilities with another system on State Of The Filesystem · · Score: 1
    Linux GUIs will have likely have the same problem with Reiser4 -> Very few users, therefore all features will be designed around the Lowest Common Denominator POSIX-type filesystem.

    This is quite possible if it is not done right, but most of the designs seem to be approaching this correctly.

    The biggest difference from NTFS is that the "metadata" is accessed using normal file open/read/write/close. This immediatly makes 95% of the software on Linux able to do something with this data. NT failed to do this obvious design (yea I know there is a lower-level interface like this, but that is NOT what existing programs use to open files!).

    The other more difficult need is to have this not screw up when files need to be stored on older file systems, which is the main problem you are talking about. I believe this can be solved by making as much metadata as possible be contained in the "data fork" of the file, so when you "cat" it you get almost all the data. Then if the file is copied to an older disk system and then copied back you will get all your metadata back. Actually most solutions will allow a new Linux+metadata system to see the metadata even if the file is on an older filesystem, as the actual extraction of metadata would be done by user-level local plugins.

    In my opinion these proposals are light years ahead of NT/Apple/BeOS in the ideas of naming, but I don't see any real attempts to solve the data problems.

  10. Re:Good article on State Of The Filesystem · · Score: 1
    There is a back-compatability problem with having "cat foo" produce all the metadata in foo (which otherwise would probably be a good idea). I like your solution of adding some more letters to the end. But we certainly don't want to reserve a new character like '#'.

    So maype "/file/" could be used to indicate "all the data in /file". "/file" would be for back-compatability and produce "the main block of data". "/file/foo" would extract subdata (metadata, attributes, and internal files) and the exact behavior would depend on the type of "/file" and on what plugins are installed in the file system.

  11. Re:Good article on State Of The Filesystem · · Score: 1
    You are describing another kludge just like tar and zip and GConf and the Windows registery and every file in /etc and all the other examples, designed to get around the limitations of current file systems. The original poster is also confused, his "boxing" sounds like the same thing.

    Ideally the "boxing" should be invisible. I would like to see "cat directory" spew a stream similar to a tar file so if you did "cp dira dirb" dirb would end up a duplicate of dira. This would allow entire hierarcies of directories and metadata to be stored on systems that don't understand the metadata, and to be transmitted as single blocks of data through email attachments and other network protocols.

  12. Re:Transferring Files on State Of The Filesystem · · Score: 3, Insightful
    Absolutely #3 is the way to go. "metadata" should always be figured out from the contents of the file, the metadata should really be considered a cache of the answers.

    The way it would work is a program would look for a piece of metadata. If it was not there it would run a standard program using popen that would then create the metadata and return it, and also set the metadata on the file if it had permission to. This program would probably work something like "file" does now and would use text configuration files to actually determine how to extract interesting information from all known file types. Most likely this actual implementation of looking up metadata would be wrapped in a libc-level function so it just looks like you ask for the metadata.

    The obvious advantages:

    Files can be transferred by protocols that don't understand metadata.

    Files can be stored on filesystems that don't understand metadata.

    Metadata is never "lost" as long as the real file data is intact.

    Metadata can be stored locally for remote files.

    Metadata can be modified without permission to modify the file.

    Probably much faster because metadata is not calculated until first needed.

    I also think that all files should be treatable as directories, and that the metadata should be presented as being inside this directory (ie the metadata "blah" for file "foo" is foo/blah). But this does not mean it has to be stored this way and does not mean it has to exist when copied.

  13. Re:Still the same problems since 2.5.68 on Linux v2.6 Begins Testing · · Score: 2, Interesting
    It seems hard to believe there is any kind of bug that is turning one keystroke into multiples and is not producing similar problems with every other X application (ie you type 'a' and get more than one 'a' in xterm).

    Therefore I would very much suspect an error in sawfish, that for some timing reason was not causing the problem with earlier Linux. Most likely other X events are coming in at unexpected times and due to some bug it is interpreting them as repeats of the keystroke. I would also suspect the reason xterm does not appear is not because it didn't launch, but because sawfish is busy getting confused by these events and is not bothering to map the window. Try making a shortcut that prints a message to a console before running xterm so you can tell exactly when sawfish decided to launch the program.

  14. Re:Useful for structs/unions on Latest Proposals for C++0x · · Score: 1
    No, it would only be illegal if the structure itself was unnamed. Since unnamed structures don't work right now, this will not be incompatable with anything.

    struct {int j; struct {int j;};} f; would be illegal because f.j is ambiguous.

    struct {int j; struct {ing j;} k;} f; would be legal. f.j is the first j, f.k.j is the second one.

  15. Re:Great... on Latest Proposals for C++0x · · Score: 1

    The newest version of the Irix compilers are fixed so you can use the new headers on them. Right now they are better than VC++6. Have not had a chance to try VC++7 yet but I heard it was much better than 6.

  16. Re:Nope on SCO's Other Investor: Sun Microsystems · · Score: 1
    No, not according to a literal interpretation of the GPL. Imagine if you started with the driver, and "modified" it by adding all the code necessary to implement Solaris. This is then a derivative of the driver and thus all that extra code must be distributed along with the driver if you distribute it. This really is what the GPL says.

    This is why the LGPL exists (if the driver was under that it probably could be added with only the changes to the driver itself released), and why there are often "exceptions" to GPL code, for instance Linux is allowed to be distributed with non-GPL modules.

    Now here is where it gets confusing, and where some people have trouble with the GPL. You could take a GPL program and run it on a closed system, and by convoluted logic consider that closed system to just be something added to the GPL program. If this is true then you are not allowed to sell a disk containing a closed operating system and a GPL program (notice that you can USE the GPL program on your closed system, you can still distribute your closed system, and you can even distribute the GPL program seperately).

    I think in reality the basic GPL has an "exception" for "the operating system" so that the above rather strange situation does not happen, this is under the "normal aggredization (sp?)" of several programs on a disk.

    Personally I feel this area confuses most people and serves no real purpose. I would like to see a license that is similar to the GPL/LGPL except you are only required to redistribute changes to the GPL/LGPL code itself, and not the code you linked with it (plus a few rules so your modification is not just "extern secret_stuff(); secret_stuff();"). This would serve the main purpose of the GPL/LGPL of preventing the hijacking / embrace&extend / proprietizing of open source code, but avoid all kinds of hassles and complex questions.

    Anybody designing a useful bit of reusable functionality is perfectly well protected with this type of license, and most people writing such software use similar licenses (typically LGPL with an exception to allow static linking) that are equivalent to that.

    But this could work fine even for things that are GPL now, such as a big word processor. Somebody *could* take one file out of that, modify it, and use it in their closed-source word processor, only distributing the changed source file. However anybody who did that would be under strong suspicion that they stole other parts of the copyrighted code, so they would be under pressure to release everything.

  17. Re:IP problems of Linux well known to Unix experts on OSCON Panel: SCO Lawsuit About the Money · · Score: 2, Interesting

    1. Jobs is already very familiar with BSD from his work on NeXT.

    2. Although their current use of BSD would not violate the Linux GPL, they may want to reserve the ability to modify the kernel and keep their modifications secret.

    3. Linux's main advantage is in drivers. Since Apple is doing all their own hardware this may have eliminated this advantage.

  18. Re:happens often on NASA Test Shows Foam Could Be Culprit · · Score: 1
    I meant that I don't think there was any memo that said "this foam is worse". I believe they thought the foams were exactly equivalent and that the benifit (however tiny) of getting rid of the CFC's was worth it as there were no negative costs. This could imply they did a bad job testing it.

    The damage caused to the enviroment by the freon based foam used in launches is peanuts to the safety and welfare of the crew and success of the mission.

    Not sure but I also suspect the environmental damage of that freon is tiny compared to whatever is released by launching the shuttle. I think it even releases a great deal of CFC's. True rabid environmentalists think we should not be flying shuttles due to pollution.

  19. Re:Not quite correct on NASA Test Shows Foam Could Be Culprit · · Score: 1
    Sounds exactly the same as what I was thinking.

    Is the ISS orbit at the ideal inclination for the Russian launch location, or do they have to change it slightly, and is the change up or down? If so, do you know what other factors went into choosing the inclination?

  20. Re:Not nuclear winter on Scientists Say Cosmic Rays May Cause Global Warming · · Score: 1

    I'll have to see those. My memories of environmental extremism during the 70's were lots and lots of "earth will end up like venus" and "the icecaps will melt and flood everything". Both were based on the assumption that the primary pollutants was CO2. Towards 1980 when there was rabid anti-nuke protests there were even people claiming that waste heat itself was going to destroy the world (they were concerned that 100% safe nuclear power may be developed and that waste heat would be the only thing they could protest). I don't remember cooling being discussed at all and actually I remember thinking the nuclear winter warnings were bogus because I "knew" that clouds in the sky trapped heat. Granted this is just the popular press, possibly there was cooling stuff in academic papers.

  21. Re:Watt smells around here? on Scientists Say Cosmic Rays May Cause Global Warming · · Score: 1

    You are confusing nuclear winter with global warming.

  22. Re:Linux is unaffected? on Linux vs. SCO: The Decision Matrix · · Score: 1
    No, if the GPL is invalid than they violated copyrights by giving away the code. Nothing other than the GPL allows them to redistribute the code. They would lose badly unless they could successfully eliminate copyright itself.

    There is enormous corporate interest in keeping copyright the way it is, including the ability to allow a receiver to violate a copyright in carefully prescribed ways (ie only your customers or the printing company you hired or a palladium-enabled browser is allowed to violate the copyright). Any useful attack on the GPL would be an attack on that, and the value of Linux (or of eliminating Linux) is diddlysquat compared to that.

  23. Re:Not quite correct on NASA Test Shows Foam Could Be Culprit · · Score: 1
    That's very interesting, and agrees with the limited knowledge that I have (which is that for a given position on the earth, one inclination is best, and it depends on the latitude. I think that inclination is equal to the latitude, but not sure).

    Does it actually take less energy to increase the inclination than to decrease it, or is just that it can be done at the ground by the booster rockets (ignore atmospheric friction any anything else complex). It does seem like the fact that the high-inclination one actually passes over the low-inclination position could make a difference to the entire energy requirement, but I'm not sure.

  24. Re:Linux is unaffected? on Linux vs. SCO: The Decision Matrix · · Score: 2, Interesting
    In that case they have violated the copyrights of all other contributors to Linux. You are not allowed to distribute Linux except under the GPL, otherwise you are violating copyright.

    Their only possible excluse is to claim lack of knowledge of putting the code into Linux. However: their failure to immediately stop distributing it before or when they published their claims, their failure to provide instructions on how to remove the offending code from the previously-distributed versions and thus make them GPL-compliant, and most damaging their claim that their own customers are not in trouble but other users of Linux are, are all going to be very bad for them. Each of these is a good proof that they knowingly violated the GPL and thus the copyrights of thousands of programmers.

  25. Not quite correct on NASA Test Shows Foam Could Be Culprit · · Score: 1
    Non-inclined orbits are not easier. As you just pointed out the ISS orbit was chosen so the Russian launches could reach it (actually it is a compromise between the idea orbits for them and for Florida and Europe), so it is obvious that some orbits are easier to reach than equatorial.

    In any case this is the first time anybody has mentioned inclination instead of altitude. Does anybody know if, assumming the shuttle had unlimited fuel, it would spend more fuel speeding up (and raising it's orbit) or changing the inclination to reach the space station?