I've been struggling with CVS for a while now, and while it does the job I've always been thinking "There's got to be something out there with recursive add built in."
That's got to be the lamest thing to complain about in CVS, and also one of the easiest things to fix yourself. If you don't have a client program that will do it for you already, you can always write a simple shell script to do it. There are good arguments for NOT doing a recursive add, and the fact that the command-line client distributed with the package chooses not to support it is almost totally irrelevant. Just how many times do you add a directory hierarchy that is deep and wide enough that you need this, anyway? I mean, oh dear, 5 subdirectories, it's just too much work! Or, you could do:
My two main objections with FTP itself: 1) plaintext passwords
There's a version of FTP which does SRP authentication distributed with the SRP package (and a telnet client and server which do the same).
2) a separate data connection, whether it's passive or active.
Using the same connection for control and data requires either: having some EOF indication (and an escape mechanism for the data); sending data in chunks with the length specified; or closing the control connection after each transfer. Using the semantics of "end of file" is "socket closed" works very well. HTTP, SOCKS, and many other protocols do essentially the same thing. Those that have both a stateful connection and transfer data (such as SMTP) have some constraints (such as SMTP doing dot stuffing). Using the same connection also makes it difficult to do things like abort a transfer cleanly, get a status update on the transfer, etc. It also allows doing a 3-way transfer (client specifying that server 1 transfer a file to server 2).
Passive data transfers work well if the client is behind a firewall.
Unless the firewall blocks most outgoing connections as well. Then passive doesn't work unless the firewall snoops and understands PASV and the response (and even then, most will only allow a passive connection to the host that the control connection is with, not allowing a passive redirect; otherwise, you could use that feature to open up an outgoing hole in the firewall to anything you wanted). I know, I know, blocking outgoing connections based on the port number is a useless exercise in futility - it might stop a dumb trojan from connecting back home, and it can prevent some worms from easily spreading using your machine (as long as the vector doesn't use those ports you allow), but try explaining that to a clueless network administrator.
Exactly right..NET is destined to become, in the end, a network bootloader that loads the latest version of the client side (including the latest versions of the CLI/CLR/.NET bytecode translators, etc.) into a local cache, from your "service provider" (i.e. Microsoft), and then run everything as a tight mix between local client and remote server (all for a tidy monthly fee). If you're running Mono, the first thing their downloaded client code will do is load their version of everything, then start running that. They may even provide a "native linux" version of it (as long as you're running the right version of the kernel and libraries). For people who don't want or need "legacy Windows" support, there will be a mini-kernel that supports only.NET, similar to the JavaOS idea.
There will be a minor place for independent software developers - Microsoft will offer to sell your.NET services to their customers, splitting the take depending on how important you are. If they change the specifications/dependencies/requirements with new versions, they'll work with the software vendors to get new versions, which will then automatically be updated when Microsoft does the switch.
Someone who wants to take Microsoft's place has to provide both the client and server side of the equation. Mono sounds like it is the client side, but connecting Mono to a non-Microsoft server will leave you without access to ANY of the services available through Microsoft; in order to be an attractive platform, you'd have to not only provide all of the Microsoft software they'll have, but convince sufficient number of 3rd party vendors to sell the software you're not able to write yourself (and Microsoft will presumably have exclusive contracts with any important ones). Connecting Mono to Microsoft servers would just be irrelevant.
C# and the.NET bytecode translator and runtime may indeed be better than Java and the JavaVM (and it might not - many of the "innovations" in C# are minor conveniences that would be easy to add to a Java compiler without changing the VM at all), but you'll probably find that even if you implement a bunch of stuff in it, it won't make you able to work with anything Microsoft puts out; you'll just be a bunch of unauthenticated unsafe code that any decent Microsoft installation will refuse to run.
I find it fascinating, by the way, that people get so hyped up about how Microkernel implementations (such as MkLinux or the Hurd) are so bad because they're so slow (which is a major overstatement, besides), yet at the same time advocate running horrible kludges like C++, or elegant kludges like Java or C# through an elegant (but slow) VM architecture.
Except that laserdiscs didn't have any usage restrictions on them and laserdiscs were the only alternative to videotape and were clearly much higher quality PLUS laserdiscs had all the advantages over tape that DVDs have over this.
"It's a Wonderful Life" is one of the few feature films that has entered the public domain. Its popularity can probably be attributed to the ability of broadcasters to show it without royalties.
Except then they found that one of the songs in the soundtrack was still under copyright, so it was no longer royalty-free (which is ridiculous - since the song was properly licensed to be used in the movie, it should be allowed regardless of the situation later on; of course, that would ONLY apply to the exact use of the song with the movie; just because the movie has gone into the public domain (because they forgot to renew the copyright, back when copyright law actually had limited time periods specified) doesn't mean that any other use of the song would be allowed).
Copyleft doesn't add any additional restrictions to normal copyright. If you can cite it now without permission, you can still cite it without complying with any additional terms, whether they be copyleft or "I own your firstborn". If copyright law currently allows you to use brief excerpts, copyleft won't change that. Simply using facts and ideas from someone else's paper doesn't make yours derivative.
Even in the case where you're trying to do something that requires permission from an author to use a work in ways that copyright doesn't automatically allow, you can STILL ask for and receive that permission.
Even if THAT person had to use copyleft because of a third copyleft work that was used, it is STILL that person's work, and as long as you use ONLY that (and none of the third work's content), you could still get permission to use it without distributing it under a copyleft license.
No, for each file (directory, symbolic link, device, pipe, etc.) you have on your system, it fills up your root partition with a file full of zeroes; each time, it deletes the file and does it again. Those particular sectors (the unused ones on the root partition) will be overwritten with zeroes multiple thousands of times, but that doesn't do much good for anything else, and it doesn't make sense to base the number of times you overwrite those particular sectors on the number of files that exist. Also, there's no guarantee that unused space at the end each file is zeroed (depends on how the file system allocates and clears space).
Re:I'll never tourch RPM again if I have too
on
OpenPKG 1.0 Released
·
· Score: 1
It's voodoo when the packages have to be listed in some specific order. Why they needed to be in a different order is beyond me. But of course, these types of circular references shouldn't exist in the first place.
RPM is supposed to re-order the packages automatically, assuming you specified them all in one command. You can either install or upgrade, and it will do the right thing. Of course, there are presumably bugs that keep it from working correctly in some cases, and circular dependencies in install scripts could also cause problems. Circular dependencies are much more of a problem with a source package, though - just think bash, make, gcc, fileutils, sh-utils, glibc, diffutils, findutils, sed, textutils - all of those have to be installed to build any of the others.
Why can't the system understand compatible and incompatible upgrades automatically and either allow the newer version to be used in place of the older version, or install it alongside the current version?
It can, of course, if the package maintainers do it correctly. You could make it have no dependencies whatsoever, or make it have ridiculously specific and superfluous dependencies. You can also screw up Makefiles, install shell scripts, or anything else - for example, use bash-specific shell syntax, but specify #!/bin/sh, and then wonder why people get upset.
Having multiple installed versions of a package is, in general, a difficult issue all by itself. There are many ways to do it, and many ways to try to figure out how to access the specific version that YOU want. Just as an example, a configure script (I think for gcc 3.0.something) wanted a version of GNU make higher than some value - it looked for the first instance of gmake or make in each directory in PATH; unfortunately, it found gmake, which RedHat installed for those programs that think they want gmake only; unfortunately, that meant it didn't find the NEW version of make which I had installed in/usr/local/bin (even though/usr/local/bin was first in PATH), because GNU make doesn't normally install itself as gmake. This was mostly a configuration error with RedHat, since there's no reason to install it as gmake when make itself IS GNU make. Solution, of course, was to either link gmake in/usr/local/bin, or delete/usr/bin/gmake. Point is, a configure script has to be a mind reader to figure out things on a completely unknown system. In this case, it needed to keep looking for both make and gmake in each directory in PATH AND keep looking if the file it finds is not a version it wants. Instead, it looked first for gmake in PATH, then make in PATH, and then did a one-time test on the result of that to determine if it was an acceptable version. In a source distribution system, the resultant error would take any unsophisticated user totally by surprise, with no idea what to do about it (even if they already had the requisite version of GNU make installed and on their PATH).
That RPM happens to be used more by people who are likely to screw it up is more an indication that it is EASIER to use, and thus more incompetent people use it. It doesn't mean competent people should have any more difficulty with it than, say, dpkg or ports or whatever.
One thing I don't like about RPM/.deb/etc is that they rely way too heavily on a database of what is installed to determine what they will install next.
You can always tell it to ignore dependencies. You might have problems if install scripts require something you don't already have, but then you said you know you have it, so it shouldn't be a problem. The dependency problem for installing things from source can be much worse, and version requirements can be much trickier (most pre-compiled packages only have dependencies on library versions, and those are easier to satisfy than some of the wacky dependencies some source packages have).
Many, many source packages use GNU autoconf/automake/autoheader/etc, Wall's Configure, imake, cook, and so on. Those seem to meet your desire to have something that will help you write a "shareable makefile of sorts". Adding a layer of "fetch things I don't have" using a variety of methods is fairly simple, but the dependency problem still comes back to bite you.
RPM source packages are very much like what you're asking for as well. One problem it solves is that original "pristine" sources are separated from whatever patches were necessary (to source, scripts, Makefiles, whatever) to get it to compile in the same environment as the build is intended for (I'm not saying source RPMs are the only ones that do that, of course). The main problem I ran into with them was that they didn't have any dependencies on what was required to BUILD them, but I haven't kept up with the latest versions, so maybe even that has improved.
Keeping a database of what is installed, what files belong to which, what files are going to have conflicts between packages, what steps are necessary to uninstall a package, what files are user-configurable files and should be saved, etc. is very useful. Even if installing things from source, I'd want something to help keep track of everything.
BTW, a bootstrap "full build" binary is on the order of about 18MB and 120 files. That's enough to re-build itself and any other package (although you'll still have plenty of packages that need other packages built first - I suppose I should see how deep the dependency chain gets when trying to build, say, GNOME or KDE!)
The Lisa Programmer's Workbench or whatever it was called was a UCSD p-code lookalike interface; I don't remember if it was actually p-code running underneath it (i.e. for all of the interface commands), but the look-and-feel (and most of the commands) were straight from the UCSD system (e.g. top line menu bar with one-character command sequences, each one erasing the top line and displaying a new menu with new items to select). I do remember that the file system was logically hierarchical, but implemented as a flat file system which stored the full path name as the file name.
You could compile programs for either the Lisa OS, Mac OS, or to run under the programming/compile environment (similar to the way you could write tools for MPW, later). It's the latter that I think compiled to p-code on the Lisa. Certainly you could also compile to 68000 machine code as well for Lisa/Mac OS itself, and write console programs that could be run under the text-only mode.
One interesting thing on the Lisa was the use of shared libraries to allow privileged system calls. I don't remember the details or how it was implemented; in some ways it was similar to the way DEC did it (in TOPS?) with privileged directories AND file names compiled in to the kernel, but with Lisa programs, the libraries had all the privileges (which allowed programs to do interesting things things, but protected the OS from being corrupted). It wasn't really designed with high security, though. Another interesting detail was how they implemented pseudo-virtual memory with only a 68000 by using probe instructions (i.e. a memory access instruction with no side effects, so that it could be restarted by the exception handler); in particular, that was how they handled automatic stack growth. The major shortcoming of the 68000 was that instructions that generated a page fault weren't universally restartable (e.g. an autoincrement memory reference). The 68010 and 68020 corrected those flaws.
Somewhere I still have some MacWorks boot diskettes, I should see if they're still readable. The Lisa boot loader was actually a linking relocating loader with a boot-time list of modules to be linked together.
GNU binutils doesn't automatically add the link-time path to the run-time load path, except on SunOS:
"The '-rpath' option may also be used on SunOS. By default, on SunOS, the linker will form a runtime search path out of all the '-L' options it is given. If a '-rpath' option is used, the runtime search path will be formed exclusively using the '-rpath' options, ignoring the '-L' options. This can be useful when using gcc, which adds many '-L' options which may be on NFS mounted filesystems.
For compatibility with other ELF linkers, if the '-R' option is followed by a directory name, rather than a file name, it is treated as the '-rpath' option.
Also sounds very much like a Gopher directory listing; contains a type, a title, and a host/port where that information can be retrieved from, including further directories. I wrote a Gopher client that kept a back-stack of each directory visited in memory, including a pointer to which directory item you used to visit the next on in the stack (the three major differences between Gopher and HTTP/HTML are: retrieved information doesn't communicate the type, you have to know what kind it is when you retrieve it (Gopher+ improves this); there is no provision for formatted text or embedded graphics (although later Gopher clients understand HTML pages); and directories are the only non-leaf type node, unless you also support HTML).
Source code is the same way -- you generally don't want other people looking over it until you've had a chance to clean it up a little bit. If you don't want to clean it up, you just don't release it. Releasing source code *always* costs time and money to a corporation.
Then make publishing the entire source code a requirement for getting legal protection (other than trade secret protections, as enforced by individually negotiated and signed agreements with customers) on the binary program. Source would include any specialized tools, Makefiles, etc. required to build it, and a specification of which versions of other published tools are needed. This would actually strengthen "intellectual property rights", as now you'd be able to see if some of your code has been stolen by another company and used in their product.
Add in a definition of when something is out-of-print and no longer supported, and remove restrictions on copying either the object or source code at that time (out-of-print provisions should apply to any other copyrights as well - but its tricky to balance it just right).
Macrovision is an analogue copy protection technology and has nothing to do with the Digital Millenium Copyright Act.
One section of the DMCA explicitly requires all analog video recorders made/sold/imported to be affected by Macrovision. One can guess that the reason it was included in the DMCA is because Macrovision is the copy-protection scheme used by DVD players - it doesn't do much good to protect the digital content if you can just record it off to a videotape by ignoring the Macrovision; at least, that's what the warped reasoning of the legislature came up with, ignoring that the reason the movie producers were supposedly so hot and bothered in the first place was that "digital copying" is "perfect"; if that's the only reason for new restrictions on copying, then why also add new restrictions to analog copying, which is "not perfect"? It would at least have been consistent to only require that digital video capture devices detect Macrovision and mark the digital data as copy-restricted in some way.
You're very confusing. You say "it doesn't have collisions" and "if a collision occurs". I think what you're saying is that with full-duplex Ethernet, going through a switch, the chip doesn't see that there's a collision (even though there is one) and thus doesn't retransmit. Depends on the switch. Some of them will store-and-forward in that case, some will generate a collision (jam it) when it sees that the destination is busy. Some will simply drop it, in which case (with UDP) you're right, you'd lose a packet.
Simple collisions won't cause loss of data on an Ethernet. The chip detects it and (usually) automatically re-transmits. UDP packet loss is usually caused by an overloaded router that doesn't have enough room to store the backlog. Re-transmission at 100Mbps won't significantly slow things down. Regardless, in a real-time protocol, it's better to throw out stale data and continue delivering on-time than it is to push everything back to avoid a small amount of data loss.
While it can be difficult to come on to the scene years later and be able to tell what was or was not obvious back then, there are many people who were thinking about such things at that time. In 1992, alpha transparency was obvious. It was obvious in 1985.
The problem with finding prior art is when a widely used technique was never written about because it was too obvious. The only reference available is in the code that was being written at the time, and much of that is no longer available.
Another problem with the way patent law works is that it doesn't take into account enabling technologies. For example, the infamous backing-store patented technique was pretty useless without sufficient inexpensive memory; many people independently considered that approach, then rejected it because (at the time) it was impractical. You could say the same thing about the patent that covers personal digital recorders - before inexpensive processors were fast enough, disk space was cheap enough, and compression techniques were good enough, actually producing a digital recorder which can play back while recording would have been impractical (and any features not useful in a video-production context wouldn't have been pursued). However, theIDEA of actually doing so was obvious. Unless there are real difficulties in developing the capability, there shouldn't be anything patentable in there. If there ARE real difficulties, where the solution isn't "mere engineering", then those specific techniques should be patentable, but just the IDEA of backing store (with an obvious implementation), a digital video recorder where you can pause the playback (with an obvious implementation), or using a multi-bit mask to define overlay transfer characteristics shouldn't be patentable, nor should "do SOMETHING using a computer" or "do SOMETHING digitally" be patentable if SOMETHING was already being done without using a computer, or without doing it digitally, unless it was monumentally non-obvious that doing it with a computer or digitally was a better way of doing it (once the enabling technology was available, of course)(obviously, I'm not commenting on whether such things ARE, in fact, patentable under previous or current law).
Next, just create a DTD for Web pages to validate spelling, grammar and requires a visually pleasing layout. Just define those up front and let a standard XML IDE enforce it, and the Web would look so much better.
I'll bet you could come up with a good XML DTD for Slashdot articles as well; just select one for Troll, Flamebait, Funny, Insightful, or whichever you're going for, and the DTD would validate the article and we could get rid of this silly moderation system altogether!
No, natural gas does NOT have added Sulfur Dioxide. That's one of the primary pollutants that expensive scrubbers are used to remove from coal exhausts and such, why would they ADD it? It is also a significant allergen in very small concentrations (I can't eat most dried apricots or golden raisins because they are treated with SO2; it is also used in making some wines, but is usually low enough concentration that it doesn't bother me). If there was SO2 in natural gas, you'd end up with it in your house from a gas stove. You need a substance that will break down when burned. Sulfur Dioxide is also not the substance that gives rotten eggs their wonderful odor; you're thinking of Hydrogen Sulfide.
The restriction on student solo flight is only in the "enhanced Class B" ("Class B veil") airspace, which is the airspace around any large airport. It is no more restricted than any other VFR (Visual Flight Rules), which was allowed as of last Thursday. What isn't clear is why flight instruction was restricted for another 2 days, until Friday evening 0000 UTC. Even more puzzling is why, if flight instruction was restricted then, it was made LESS restrictive after the ban was lifted (flight instruction in small airplanes is allowed EVEN IN the Class B veil, unlike any other VFR flight).
Microsoft doesn't have to support it, OEMs have to support it for it to become popular. They can install the drivers for it if they're installing the hardware, so it doesn't have to be part of a default Windows installation.
Support from the Wintel world is necessary to get prices into the reasonable range. If PCs had gone with SCSI rather than IDE, SCSI drives would be the cheap ones now. Diskettes are cheap now because everyone uses them; when they first came out, and only Macs could use them, they were $5 each (for a 400K single-sided diskette). However, Apple support DOES have an influence - look at the price of SCSI drives after Apple stopped using them as the standard internal drive. Prices soared.
Is there anything inherently more expensive about Firewire than USB (in either version)? How do the two higher-speed versions of each handle backwards compatibility with the the slower-speed version?
RC4's "goodness" is very dependent on how it is used. Many of the attacks on WEP would work as well regardless of the stream cypher used; the problem was the poor implementation (e.g. the integrity check, weak key generation, small IV space). See, e.g. (In)Security of the WEP algorithm.
The "Weaknesses in the Key Scheduling Algorithm for RC4" paper (PDF or Postscript) also describes significant attacks on RC4. However, RC4 can be used in other ways; example would be to use RC4 output bytes as successive keys to a block algorithm (e.g. DES, or multiple DES with a separate key for each); there are other ways to use a stream cypher output in more secure ways.
Slashdot Mirror
CVS started out as a collection of shell scripts in 1986.
That's got to be the lamest thing to complain about in CVS, and also one of the easiest things to fix yourself. If you don't have a client program that will do it for you already, you can always write a simple shell script to do it. There are good arguments for NOT doing a recursive add, and the fact that the command-line client distributed with the package chooses not to support it is almost totally irrelevant. Just how many times do you add a directory hierarchy that is deep and wide enough that you need this, anyway? I mean, oh dear, 5 subdirectories, it's just too much work! Or, you could do:
cvs -d /cvs co -l .
find project | xargs cvs add
cvs commit
Or, as someone else pointed out, you can just use cvs import.
There's a version of FTP which does SRP authentication distributed with the SRP package (and a telnet client and server which do the same).
Using the same connection for control and data requires either: having some EOF indication (and an escape mechanism for the data); sending data in chunks with the length specified; or closing the control connection after each transfer. Using the semantics of "end of file" is "socket closed" works very well. HTTP, SOCKS, and many other protocols do essentially the same thing. Those that have both a stateful connection and transfer data (such as SMTP) have some constraints (such as SMTP doing dot stuffing). Using the same connection also makes it difficult to do things like abort a transfer cleanly, get a status update on the transfer, etc. It also allows doing a 3-way transfer (client specifying that server 1 transfer a file to server 2).
Unless the firewall blocks most outgoing connections as well. Then passive doesn't work unless the firewall snoops and understands PASV and the response (and even then, most will only allow a passive connection to the host that the control connection is with, not allowing a passive redirect; otherwise, you could use that feature to open up an outgoing hole in the firewall to anything you wanted). I know, I know, blocking outgoing connections based on the port number is a useless exercise in futility - it might stop a dumb trojan from connecting back home, and it can prevent some worms from easily spreading using your machine (as long as the vector doesn't use those ports you allow), but try explaining that to a clueless network administrator.
Exactly right. .NET is destined to become, in the end, a network bootloader that loads the latest version of the client side (including the latest versions of the CLI/CLR/.NET bytecode translators, etc.) into a local cache, from your "service provider" (i.e. Microsoft), and then run everything as a tight mix between local client and remote server (all for a tidy monthly fee). If you're running Mono, the first thing their downloaded client code will do is load their version of everything, then start running that. They may even provide a "native linux" version of it (as long as you're running the right version of the kernel and libraries). For people who don't want or need "legacy Windows" support, there will be a mini-kernel that supports only .NET, similar to the JavaOS idea.
There will be a minor place for independent software developers - Microsoft will offer to sell your .NET services to their customers, splitting the take depending on how important you are. If they change the specifications/dependencies/requirements with new versions, they'll work with the software vendors to get new versions, which will then automatically be updated when Microsoft does the switch.
Someone who wants to take Microsoft's place has to provide both the client and server side of the equation. Mono sounds like it is the client side, but connecting Mono to a non-Microsoft server will leave you without access to ANY of the services available through Microsoft; in order to be an attractive platform, you'd have to not only provide all of the Microsoft software they'll have, but convince sufficient number of 3rd party vendors to sell the software you're not able to write yourself (and Microsoft will presumably have exclusive contracts with any important ones). Connecting Mono to Microsoft servers would just be irrelevant.
C# and the .NET bytecode translator and runtime may indeed be better than Java and the JavaVM (and it might not - many of the "innovations" in C# are minor conveniences that would be easy to add to a Java compiler without changing the VM at all), but you'll probably find that even if you implement a bunch of stuff in it, it won't make you able to work with anything Microsoft puts out; you'll just be a bunch of unauthenticated unsafe code that any decent Microsoft installation will refuse to run.
I find it fascinating, by the way, that people get so hyped up about how Microkernel implementations (such as MkLinux or the Hurd) are so bad because they're so slow (which is a major overstatement, besides), yet at the same time advocate running horrible kludges like C++, or elegant kludges like Java or C# through an elegant (but slow) VM architecture.
Except that laserdiscs didn't have any usage restrictions on them and laserdiscs were the only alternative to videotape and were clearly much higher quality PLUS laserdiscs had all the advantages over tape that DVDs have over this.
Except then they found that one of the songs in the soundtrack was still under copyright, so it was no longer royalty-free (which is ridiculous - since the song was properly licensed to be used in the movie, it should be allowed regardless of the situation later on; of course, that would ONLY apply to the exact use of the song with the movie; just because the movie has gone into the public domain (because they forgot to renew the copyright, back when copyright law actually had limited time periods specified) doesn't mean that any other use of the song would be allowed).
Copyleft doesn't add any additional restrictions to normal copyright. If you can cite it now without permission, you can still cite it without complying with any additional terms, whether they be copyleft or "I own your firstborn". If copyright law currently allows you to use brief excerpts, copyleft won't change that. Simply using facts and ideas from someone else's paper doesn't make yours derivative.
Even in the case where you're trying to do something that requires permission from an author to use a work in ways that copyright doesn't automatically allow, you can STILL ask for and receive that permission.
Even if THAT person had to use copyleft because of a third copyleft work that was used, it is STILL that person's work, and as long as you use ONLY that (and none of the third work's content), you could still get permission to use it without distributing it under a copyleft license.
What about CD/RW? How much of a trace is left when that is zeroed out?
No, for each file (directory, symbolic link, device, pipe, etc.) you have on your system, it fills up your root partition with a file full of zeroes; each time, it deletes the file and does it again. Those particular sectors (the unused ones on the root partition) will be overwritten with zeroes multiple thousands of times, but that doesn't do much good for anything else, and it doesn't make sense to base the number of times you overwrite those particular sectors on the number of files that exist. Also, there's no guarantee that unused space at the end each file is zeroed (depends on how the file system allocates and clears space).
RPM is supposed to re-order the packages automatically, assuming you specified them all in one command. You can either install or upgrade, and it will do the right thing. Of course, there are presumably bugs that keep it from working correctly in some cases, and circular dependencies in install scripts could also cause problems. Circular dependencies are much more of a problem with a source package, though - just think bash, make, gcc, fileutils, sh-utils, glibc, diffutils, findutils, sed, textutils - all of those have to be installed to build any of the others.
It can, of course, if the package maintainers do it correctly. You could make it have no dependencies whatsoever, or make it have ridiculously specific and superfluous dependencies. You can also screw up Makefiles, install shell scripts, or anything else - for example, use bash-specific shell syntax, but specify #!/bin/sh, and then wonder why people get upset.
Having multiple installed versions of a package is, in general, a difficult issue all by itself. There are many ways to do it, and many ways to try to figure out how to access the specific version that YOU want. Just as an example, a configure script (I think for gcc 3.0.something) wanted a version of GNU make higher than some value - it looked for the first instance of gmake or make in each directory in PATH; unfortunately, it found gmake, which RedHat installed for those programs that think they want gmake only; unfortunately, that meant it didn't find the NEW version of make which I had installed in /usr/local/bin (even though /usr/local/bin was first in PATH), because GNU make doesn't normally install itself as gmake. This was mostly a configuration error with RedHat, since there's no reason to install it as gmake when make itself IS GNU make. Solution, of course, was to either link gmake in /usr/local/bin, or delete /usr/bin/gmake. Point is, a configure script has to be a mind reader to figure out things on a completely unknown system. In this case, it needed to keep looking for both make and gmake in each directory in PATH AND keep looking if the file it finds is not a version it wants. Instead, it looked first for gmake in PATH, then make in PATH, and then did a one-time test on the result of that to determine if it was an acceptable version. In a source distribution system, the resultant error would take any unsophisticated user totally by surprise, with no idea what to do about it (even if they already had the requisite version of GNU make installed and on their PATH).
That RPM happens to be used more by people who are likely to screw it up is more an indication that it is EASIER to use, and thus more incompetent people use it. It doesn't mean competent people should have any more difficulty with it than, say, dpkg or ports or whatever.
You can always tell it to ignore dependencies. You might have problems if install scripts require something you don't already have, but then you said you know you have it, so it shouldn't be a problem. The dependency problem for installing things from source can be much worse, and version requirements can be much trickier (most pre-compiled packages only have dependencies on library versions, and those are easier to satisfy than some of the wacky dependencies some source packages have).
Many, many source packages use GNU autoconf/automake/autoheader/etc, Wall's Configure, imake, cook, and so on. Those seem to meet your desire to have something that will help you write a "shareable makefile of sorts". Adding a layer of "fetch things I don't have" using a variety of methods is fairly simple, but the dependency problem still comes back to bite you.
RPM source packages are very much like what you're asking for as well. One problem it solves is that original "pristine" sources are separated from whatever patches were necessary (to source, scripts, Makefiles, whatever) to get it to compile in the same environment as the build is intended for (I'm not saying source RPMs are the only ones that do that, of course). The main problem I ran into with them was that they didn't have any dependencies on what was required to BUILD them, but I haven't kept up with the latest versions, so maybe even that has improved.
Keeping a database of what is installed, what files belong to which, what files are going to have conflicts between packages, what steps are necessary to uninstall a package, what files are user-configurable files and should be saved, etc. is very useful. Even if installing things from source, I'd want something to help keep track of everything.
BTW, a bootstrap "full build" binary is on the order of about 18MB and 120 files. That's enough to re-build itself and any other package (although you'll still have plenty of packages that need other packages built first - I suppose I should see how deep the dependency chain gets when trying to build, say, GNOME or KDE!)
The Lisa Programmer's Workbench or whatever it was called was a UCSD p-code lookalike interface; I don't remember if it was actually p-code running underneath it (i.e. for all of the interface commands), but the look-and-feel (and most of the commands) were straight from the UCSD system (e.g. top line menu bar with one-character command sequences, each one erasing the top line and displaying a new menu with new items to select). I do remember that the file system was logically hierarchical, but implemented as a flat file system which stored the full path name as the file name.
You could compile programs for either the Lisa OS, Mac OS, or to run under the programming/compile environment (similar to the way you could write tools for MPW, later). It's the latter that I think compiled to p-code on the Lisa. Certainly you could also compile to 68000 machine code as well for Lisa/Mac OS itself, and write console programs that could be run under the text-only mode.
One interesting thing on the Lisa was the use of shared libraries to allow privileged system calls. I don't remember the details or how it was implemented; in some ways it was similar to the way DEC did it (in TOPS?) with privileged directories AND file names compiled in to the kernel, but with Lisa programs, the libraries had all the privileges (which allowed programs to do interesting things things, but protected the OS from being corrupted). It wasn't really designed with high security, though. Another interesting detail was how they implemented pseudo-virtual memory with only a 68000 by using probe instructions (i.e. a memory access instruction with no side effects, so that it could be restarted by the exception handler); in particular, that was how they handled automatic stack growth. The major shortcoming of the 68000 was that instructions that generated a page fault weren't universally restartable (e.g. an autoincrement memory reference). The 68010 and 68020 corrected those flaws.
Somewhere I still have some MacWorks boot diskettes, I should see if they're still readable. The Lisa boot loader was actually a linking relocating loader with a boot-time list of modules to be linked together.
GNU binutils doesn't automatically add the link-time path to the run-time load path, except on SunOS:
Also sounds very much like a Gopher directory listing; contains a type, a title, and a host/port where that information can be retrieved from, including further directories. I wrote a Gopher client that kept a back-stack of each directory visited in memory, including a pointer to which directory item you used to visit the next on in the stack (the three major differences between Gopher and HTTP/HTML are: retrieved information doesn't communicate the type, you have to know what kind it is when you retrieve it (Gopher+ improves this); there is no provision for formatted text or embedded graphics (although later Gopher clients understand HTML pages); and directories are the only non-leaf type node, unless you also support HTML).
Then make publishing the entire source code a requirement for getting legal protection (other than trade secret protections, as enforced by individually negotiated and signed agreements with customers) on the binary program. Source would include any specialized tools, Makefiles, etc. required to build it, and a specification of which versions of other published tools are needed. This would actually strengthen "intellectual property rights", as now you'd be able to see if some of your code has been stolen by another company and used in their product.
Add in a definition of when something is out-of-print and no longer supported, and remove restrictions on copying either the object or source code at that time (out-of-print provisions should apply to any other copyrights as well - but its tricky to balance it just right).
One section of the DMCA explicitly requires all analog video recorders made/sold/imported to be affected by Macrovision. One can guess that the reason it was included in the DMCA is because Macrovision is the copy-protection scheme used by DVD players - it doesn't do much good to protect the digital content if you can just record it off to a videotape by ignoring the Macrovision; at least, that's what the warped reasoning of the legislature came up with, ignoring that the reason the movie producers were supposedly so hot and bothered in the first place was that "digital copying" is "perfect"; if that's the only reason for new restrictions on copying, then why also add new restrictions to analog copying, which is "not perfect"? It would at least have been consistent to only require that digital video capture devices detect Macrovision and mark the digital data as copy-restricted in some way.
You're very confusing. You say "it doesn't have collisions" and "if a collision occurs". I think what you're saying is that with full-duplex Ethernet, going through a switch, the chip doesn't see that there's a collision (even though there is one) and thus doesn't retransmit. Depends on the switch. Some of them will store-and-forward in that case, some will generate a collision (jam it) when it sees that the destination is busy. Some will simply drop it, in which case (with UDP) you're right, you'd lose a packet.
Simple collisions won't cause loss of data on an Ethernet. The chip detects it and (usually) automatically re-transmits. UDP packet loss is usually caused by an overloaded router that doesn't have enough room to store the backlog. Re-transmission at 100Mbps won't significantly slow things down. Regardless, in a real-time protocol, it's better to throw out stale data and continue delivering on-time than it is to push everything back to avoid a small amount of data loss.
While it can be difficult to come on to the scene years later and be able to tell what was or was not obvious back then, there are many people who were thinking about such things at that time. In 1992, alpha transparency was obvious. It was obvious in 1985.
The problem with finding prior art is when a widely used technique was never written about because it was too obvious. The only reference available is in the code that was being written at the time, and much of that is no longer available.
Another problem with the way patent law works is that it doesn't take into account enabling technologies. For example, the infamous backing-store patented technique was pretty useless without sufficient inexpensive memory; many people independently considered that approach, then rejected it because (at the time) it was impractical. You could say the same thing about the patent that covers personal digital recorders - before inexpensive processors were fast enough, disk space was cheap enough, and compression techniques were good enough, actually producing a digital recorder which can play back while recording would have been impractical (and any features not useful in a video-production context wouldn't have been pursued). However, theIDEA of actually doing so was obvious. Unless there are real difficulties in developing the capability, there shouldn't be anything patentable in there. If there ARE real difficulties, where the solution isn't "mere engineering", then those specific techniques should be patentable, but just the IDEA of backing store (with an obvious implementation), a digital video recorder where you can pause the playback (with an obvious implementation), or using a multi-bit mask to define overlay transfer characteristics shouldn't be patentable, nor should "do SOMETHING using a computer" or "do SOMETHING digitally" be patentable if SOMETHING was already being done without using a computer, or without doing it digitally, unless it was monumentally non-obvious that doing it with a computer or digitally was a better way of doing it (once the enabling technology was available, of course)(obviously, I'm not commenting on whether such things ARE, in fact, patentable under previous or current law).
When did the Amiga Toaster come out?
Next, just create a DTD for Web pages to validate spelling, grammar and requires a visually pleasing layout. Just define those up front and let a standard XML IDE enforce it, and the Web would look so much better.
I'll bet you could come up with a good XML DTD for Slashdot articles as well; just select one for Troll, Flamebait, Funny, Insightful, or whichever you're going for, and the DTD would validate the article and we could get rid of this silly moderation system altogether!
No, they used 555-xxxx numbers for fictional numbers long before that song was ever written. Probably long before Jenny was even born.
No, natural gas does NOT have added Sulfur Dioxide. That's one of the primary pollutants that expensive scrubbers are used to remove from coal exhausts and such, why would they ADD it? It is also a significant allergen in very small concentrations (I can't eat most dried apricots or golden raisins because they are treated with SO2; it is also used in making some wines, but is usually low enough concentration that it doesn't bother me). If there was SO2 in natural gas, you'd end up with it in your house from a gas stove. You need a substance that will break down when burned. Sulfur Dioxide is also not the substance that gives rotten eggs their wonderful odor; you're thinking of Hydrogen Sulfide.
The restriction on student solo flight is only in the "enhanced Class B" ("Class B veil") airspace, which is the airspace around any large airport. It is no more restricted than any other VFR (Visual Flight Rules), which was allowed as of last Thursday. What isn't clear is why flight instruction was restricted for another 2 days, until Friday evening 0000 UTC. Even more puzzling is why, if flight instruction was restricted then, it was made LESS restrictive after the ban was lifted (flight instruction in small airplanes is allowed EVEN IN the Class B veil, unlike any other VFR flight).
IAAFI (I Am A Flight Instructor).
Microsoft doesn't have to support it, OEMs have to support it for it to become popular. They can install the drivers for it if they're installing the hardware, so it doesn't have to be part of a default Windows installation.
Support from the Wintel world is necessary to get prices into the reasonable range. If PCs had gone with SCSI rather than IDE, SCSI drives would be the cheap ones now. Diskettes are cheap now because everyone uses them; when they first came out, and only Macs could use them, they were $5 each (for a 400K single-sided diskette). However, Apple support DOES have an influence - look at the price of SCSI drives after Apple stopped using them as the standard internal drive. Prices soared.
Is there anything inherently more expensive about Firewire than USB (in either version)? How do the two higher-speed versions of each handle backwards compatibility with the the slower-speed version?
RC4's "goodness" is very dependent on how it is used. Many of the attacks on WEP would work as well regardless of the stream cypher used; the problem was the poor implementation (e.g. the integrity check, weak key generation, small IV space). See, e.g. (In)Security of the WEP algorithm.
The "Weaknesses in the Key Scheduling Algorithm for RC4" paper (PDF or Postscript) also describes significant attacks on RC4. However, RC4 can be used in other ways; example would be to use RC4 output bytes as successive keys to a block algorithm (e.g. DES, or multiple DES with a separate key for each); there are other ways to use a stream cypher output in more secure ways.