Can somebody help me understand the difference in how major version numbers work between free software and commercial software?
Sure. Commercial software always uses version numbers to indicate minor and major changes, whereas open source software uses version numbers willy-nilly.
Let's look at Sun for example. Long ago, we had SunOS 4.0. This continued until Sun was ready for the next major version of their OS. Instead of calling it SunOS 5.0, they created a new product line and called it Solaris 2.0. To stem confusion, the older versions of SunOS were re-branded with the Solaris moniker, so that Solaris 1.4 was equivalent to SunOS 4.4 and Solaris 1.3 was equivalent to SunOS 4.3, and so on. Thus, managers could easily see that they needed to upgrade if they were told that they were running Solaris 1.4 instead of 2.0, whereas SunOS 4.4 versus Solaris 2.0 was simply too confusing.
To further help decision-makers, Solaris 2.7 was also named Solaris 7.0, in addition to SunOS 5.7 and Solaris 9.0 is also known as Solaris 2.9 or SunOS 5.9. This continues until today where IT managers can easily see if they need to upgrade by converting the new Solaris number into the old Solaris number for machines running versions of Solaris greater than 7.0 and converting SunOS numbers into old Solaris numbers.
So anyone can clearly see that commercial software vendors use versioning in order to minimize confusion among users.
On the other hand, open source developers are continually inflating version numbers in order to compete with other open source developers for precious clients. For examples, one has to look no further than the Linux even-stable/odd-development scheme or FreeBSD's branches. Obviously these developers are only attempting to confuse users through versioning in order to increase sales.
In addition, many open source efforts are constrained by the vagaries of their marketing departments. For example, Knuth's TeX approaches pi with each new version. Obviously, this was a shrewd tactic on the part of his marketing people to entice those mathematically-inclined (and how successful it was!).
When you call realloc, you're very likely to cause the data to be copied from the old buffer to the new buffer. This is very high overhead. The article discusses how to do similar things, but without this unecessary copying (eg, low overhead). It's actually not that interesting of an article as what it describes is hardly new and I believe any competent programmer could come up with that solution when faced with the particular circumstances that inspired it.
Realloc works by seeing if there is free memory after the end of the allocated block, and changing the block's size if so. Realloc can do this because it knows about the internals of the malloc/free implementation. If there is allocated memory right after the block in question, a new block must be allocated, as you cannot "move" the later block in a language like C where any memory location can be a pointer. You could try this kind of stuff in other languages (or in some bastardized C where you do not have direct access to memory, but go through more indirection, the next logical abstraction after the article), but when you start automatically finding/checking/updating memory pointers, you get into GC.
You may be able to overcome some overhead on realloc if you move the problem down into the kernel. The kernel could play page table games so there is little or no actual copying involved, just updating of page tables. This would be fairly easy to implement, but I don't think anyone's done it because (a) flushing the relevant TLB entries could hurt performance more than the copying, and (b) the system call overhead might be more overhead than the copying. Realloc is generally only used for small buffers (due to programmers knowing about the copying overhead) and this trick would only have gains for large buffers spanning multiple pages. For small buffers, the library-level realloc could avoid the system call and do the copying itself, avoiding system call overhead and TLB entry flushes.
This scheme I describe could make for an interesting paper (especially determining for what size of buffer and what type of program it has gains), but I doubt it would make much difference in real system performance as programmers avoid realloc for large buffers, and there are very few cases where one needs direct linear access to a large range of memory rather than being better-served by organizing that memory into some data structure.
Anyone have any good data on cost per page for inkjet printers vs. laser?
A member of our IT department did a report on exactly this about a year ago. I don't have the report with me, but I can dig up details if required. The laser printers we evaluated were high-end workgroup printers and we took all costs into consideration (initial investment, rollers, maintenance kits, labor (whether we have an in-house technician or contract out the maintenance)).
We also used more realistic estimates on toner/ink usage than the industry defines. The standard industry test for toner cartridge life is at 5% coverage: they have a standard letter they send through the printer multiple times to see how long toner lasts.
I wrote the print server software we use and for a few months I calculated and kept logs of ink coverage (on spare CPU cycles, render pages from postscript using printer's DPI and count pixels based on a gray-level heuristic that makes the standard test page come out at 5%). In (what I would call) a normal office environment, our coverage was around 8%, significantly higher than the "industry standard." There are lots of variables here, but the numbers we got for coverage roughly matched how much toner we actually purchased versus pagecount (also logged systematically). As such, I would not put much faith into the numbers printer manufacturers give you. The cartridges we buy are either refilled or we get a good enough volume deal on OEM cartridges that they cost the same as refilled.
Anyway, end results:
Laser: circa $0.07 / page
Inkjet: circa $0.25 / page
The inkjets costs were driven that high not just by cost of ink, but by cost of initial investment and maintenance. We usually have a lifecycle of at least four years on our laser printers in a high volume environment, but our investigations turned up the the average lifecycle of a personal inkjet is about two years.
Also important is that most inkjets are simply thrown away when there is something wrong with them but laserjets like the ones we use are repaired and eventually retired to lower-volume environments, but rarely scrapped.
If you're looking at a personal laser printer instead of higher-end workgroup stuff the difference will of course fall (similarly to how the difference would grow if you're looking at professional print-shop stuff), but I'm pretty sure the savings would still be significant. As for myself, I don't own a printer - I just print my personal stuff after-hours at work:)
In contrast, every object in Windows NT, from files to operating system data structures, has an access control list and its use can be regulated as appropriate. Linux security is all-or-nothing.
Let me ask you this: how can you restrict privileges to the RPCSS service?
Well?
I'm still waiting for an answer.
The answer is that you cannot restrict privileges to the RPCSS service. It must run as SYSTEM, the NT equivalent of root. Although ACLs can be applied to the SYSTEM account, they can be bypassed easily as SYSTEM can insert code to run at IA32 ring zero.
Let us then see how many services run by default under the SYSTEM account in a Windows machine: well, that's all of them, isn't it?
Why don't we try a little experiment. Lets take a ridiculously trivial service, one that can be written in minutes: the Messenger service.
Now let's take Messenger and run it under a different account so we can apply access controls to it. What does it do?
"Could not start the messenger service on Local Computer.
Error 1079: The account specified for this service is different from the account specified for other services running in the same process."
Well, now what does this mean? Perhaps I did not give the Messenger service a privileged enough account? Nope. Perhaps I need to restart the computer rather than starting the service directly? Nope.
The problem is that Messenger runs as a thread under svchost.exe, as it is an RPC service "built into" the various other crap there. Is this a fine-grained security model?
Note also that when you attempt to have a service start under different credentials (should you ever attempt this as I very seldom see it), you must type the account's password. Perhaps this is a security feature so that one cannot install a service which then grants the user elevated privileges? Nope.
In order to change credentials in NT ("obtain a security token"), you must supply the account's password. When you have a service run under a different account, that password that you type in is saved somewhere as it must be supplied in order to obtain different credentials. Where is it saved? Beats me. How is it stored? Probably "encrypted" using some machine-specific information; however, it must be decrypted upon launch of the service, so the password must be recoverable (without undue computation, eg, it is not hashed).
Linux system administrators must spend huge amounts of time understanding the latest Linux bugs and determining what to do about them.
...
Configuring Linux security requires an administrator to be an expert in the intricacies of the operating system and how components interact.
Again, let me pose a question to you, as I assume you see yourself as a competent NT administrator:
How do you disable DCOM without restricting RPC?
You cannot consult google, but must discover the answer on your own.
Obvious response: firewall.
Well, a firewall isn't the answer. Say box X needs to talk to box Y using DCE RPC. You cannot insert any firewall I know of between X and Y which stops DCOM but allows through other RPC programs as no firewall I know of works at this level of the stack. You could perhaps put something like a snort box in between X and Y that allows for user-programmable packet inspection, but please don't tell me that's "easy to set up and administer".
Correct response is documented here.
But a competent NT administrator such as you knew that, of course.
Let's tackle the equivalent problem on a Unix machine: we have an RPC service that we want to disable. Well, which one do we want to disable? NFS? Stop nfsd from launching. YP? Stop ypbind from launching. Mountd? Stop mountd from launching. You get the idea.
It would be really nice if the headline actually linked to Apple's knowlege base article on this update. I can't find it and I can't even get the README file since it's not in Software Update.
What I want to know is how much of the backend stuff they've changed. For instance, if they've upgraded gcc. It doesn't really affect me if the front end breaks, but I have a largish project which I'm right now preparing for release and I need to decide whether to build now or to run the update and go through another testing cycle. My intuition tells me to build now and update later, but I don't know if they've fixed any massive compiler bugs.
Isn't there a way to have Windows "run as" a different user (ala +s on UNIX)?
No, Windows doesn't have setuid executables, but if it did that would be a quick fix to his problem. The "run as different user" feature prompts the user for the target account's password before running. The proper solution would be to give the account access to read those non-filesystem sectors on the CD, but I have no idea what API games use to implement this.
It also may be difficult to reimplement the "run as" feature so it does not ask for a password. Windows does not have any equivalent to a "setuid" system call: to change a program's credentials, one must provide a password. You can see this when you try to run a service under a different account: it will prompt you for the target account's password if you don't have the service run under SYSTEM (svchost runs under SYSTEM (the real equivalent to root, more privileged than administrators), so services don't need a password to run under that account). This password is then saved somewhere (not sure where or how, but the calls require plaintext passwords so it must be recoverable). When Windows apologists claim that the Windows security architecture is well-designed but it only has been tainted by backwards-compatibility, this is one of the examples I use to refute their claims.
It may be possible to build an executable that has an administrator password built into it. The idea is that you have a service (running as SYSTEM) and then a small program that communicates with the service and asks it to launch an executable. The service has the password built into it (or stored somewhere), so the user is never prompted for a password. Or equivalently, the service runs under the target account and you let Windows save the password for you (presumably, Windows will somehow obscure the password). Obviously, this makes the password available in cleartext to available to anyone who can boot off a Linux floppy and bypass filesystem controls, but I'm guessing you're not worried about your kids doing this.
Writing such a service is very non-trivial. The security APIs it uses are very poorly documented and you have to go through all kinds of loops to allow a service to interact with the user's desktop (necessary for the spawned game process). This stuff is so horrid that I don't touch it without getting paid, but I'm available for consulting work if it's that important to anyone:)
Does anybody else here readily run arbitrary code posted just to see "what it does and how it works"?
Well, if you're worried about running the code, I can tell you what it does: it will give you a parse error, as I included square brackets where I shouldn't have. Since nobody has yet noticed the syntax error and since all three lines of the script were 100% open source, I'm forced to assume that this is a failure of the open source code review model.
I'll be sure to include a pgp signature the next time I post a one-liner.
I woulnd't mind a solution to this bloody "kmod: failed to exec/sbin/modprobe -s -k binfmt-498b, errno = 8" error I'm experiencing.
Your kernel is being asked to execute some binary whose first two bytes are 498B. This is a binary file but not an ELF executable; it seems likely that some program is attempting to exec a random binary data file or you have some filesystem corruption. Errno 8 is ENOEXEC, file is not a recognized executable format.
You can track it down with something like this:
#!/bin/sh if [ od -x -N 2 "$@" | fgrep 498b >/dev/null 2>&1 ] ; then echo "$@" fi
Save that as/tmp/foo, chmod +x it and then do:
find / -type f -exec/tmp/foo {} \;
Wait for a while and it should give you a list of the candidate files. There are a number of ways to proceed from there. For instance, I would make one of the files a shell script that logs the parent process to a file so you can find out where it's being execed. Like this:
#!/bin/sh date >>/var/log/exec-problem cat/proc/$PPID/cmdline >>/var/log/exec-problem
When filling out online forms its always worth putting "tagged" address like slashdot@domain.org, linux.com@domain.org.
I've been doing this for over five years and my "real" address has (thank goodness) never got out (I only give it to humans). Over the course of five years, I've only accumulated about twenty or thirty procmail rules to discard mail to addresses that have been sold or leaked (most often via lax policy on someone else's website where large numbers of user addresses were posted). I also
threw together an emacs lisp hack for gnus
that automatically generates a new address whenever I post to usenet. I get literally zero spam and I never worry about legitimate mail not getting through.
For those who think having a vanity domain and mucking with sendmail is not worth it - there are other ways to do this. I believe sendmail's defaults allow you to send mail to "account+foo@example.com" where foo is any arbitrary string. I know for certain that qmail allows you to send mail to account-foo@example.com out of the box.
I'm so happy with this setup that whenever a spam-related story comes up on Slashdot, I post this same information. Gotta share the love.
it is not possible, looking at the software code, to determine how the program would run
This is incorrect. It is indeed possible to determine how an arbitrary program will function by looking at and analyzing the code. Rather, the Halting Problem states that it is impossible to write a program that will make this determination.
The Halting Problem has nothing to do with the execution environment (compiler, OS, hardware, etc). The idea that you cannot trust software because of the execution environment was popularized by Brian Kernighan.
WARNING: SPOILER - the Halting Problem is interesting enough that it should be studied in proper context (in a Complexity class), and not from me, who may fubar it up.
The Halting Problem works on Turing Machines, which are a simplified model of computation, but provably equivalent to most other reasonable models of computation. You can think of a Turing machine as a software function/subroutine or a hardware machine, but that does not change what it can compute (they were originally described as mechanical devices - there were no electronic computers at that time).
It is very tedious to write Turing machines but they can be analyzed with a level of mathematical rigor not feasible with modern programming languages, or even assembly languages. The relevant properties of Turing machines is that a Turing Machine M is given input A before starting. M may do one of two things: it may halt or it may loop forever. If M halts, it will output an answer, a binary yes or no.
The Halting Problem states:
It is impossible to writing a Turing machine "HALTS(M, A)" which on input (M, A) halts with TRUE if M(A) halts and halts with FALSE if M(A) does not halt.
Proof:
Consider a new program FOO(M). FOO can be described as follows:
If HALTS(M, FOO) returns FALSE, then halt and return TRUE.
If HALTS(M, FOO) returns TRUE, then loop infinitely.
Does FOO(FOO) halt?
FOO can be described as a Turing machine and HALTS must be a Turing machine as well, so FOO is a perfectly valid Turing machine. However, FOO either leads to a contradiction or has unspecified behaviour, so some part of FOO must not be a valid Turing machine. The only unspecified part is the subroutine HALTS, so it must not be a valid Turing machine.
This does not mean that programs cannot be analyzed mathematically (and there are various techniques to do this, loop invariants being one real-world-applicable example), but it means that it is impossible to write programs that do certain things (that is, the Halting Problem helps define what's computable).
Imagine if Turing machines could ask for input from a human during their execution and you were the subroutine HALTS(M, A). What would you answer when asked HALTS(FOO, FOO)? I would answer that humans are not a reasonable model of computation:)
I was able to download/pub/ls-lR from ftp.sco.com (216.250.128.13) 74.91 KB/s (600 Kb/s). My broadband is rated at 640 Kb/s, so the bottleneck was likely at my end. These machines are almost certainly on the same subnet and are likely connected to the same gear (SCO's subnetting is their choice, but if ftp.sco.com and www.sco.com are on different subnets, their subnet masks are 255.255.255.254 and they must have only two IPs per subnet - I don't believe this is even possible as you need a network and a broadcast IP for each subnet).
The fact that all of these machines are reachable and that at least one of them can saturate a broadband link indicates that SCO is not having any bandwidth problems. I also performed some ICMP tests and the machine is not sending out port-unreachables, timestamp-replies or netmask-replies - these seem blocked upstream. I'm getting a little nervous sending out these funny packets as I don't want anyone to accuse me of anything, but everything indicates that the machine is completely offline. If they allowed some ICMP replies through upstream, receiving a reply would show that the machine is actually online, but somehow cannot handle TCP requests (and the problem is not bandwidth as shown, so it would have to be something wrong with the host, such as a firewall rule); if they allowed through ICMP replies and the machine did not respond whereas others on the subnet did respond, it would show that the machine is almost definitely offline unless it has a more restrictive firewall than the other machines (very unlikely given that this, as-claimed, could have been prevented with syncookies). As it stands, one can only say that the machine is very likely offline (unplugged or turned off).
SCO's incoming mail server seems to be working fine. They only have one MX record for sco.com and it resolves to 216.250.130.2 for me at the moment. I only connected to it and saw a banner, but easy way to test this further is to send a message to an invalid address @sco.com and see if a bounce gets back. I don't want to give them an email address.
All of this is current as of 2003-12-10 21:57, Mountain time (SCO is in Utah). Further investigation lead nowhere; thus the delay in the post.
The adjective meaning "from or having to do with China" is spelt Chinese, not Chineese. SilentSage (original poster) got it wrong (consistently) and now this new word is propagating. Posting history would indicate that SilentSage is American and you are Canadian. Sic transit gloria mundi.
Correction: the hash algorithm is not MD5. I heard someone mention MD5 and assumed they were correct without checking, but the hashes are actually much longer than MD5. The hashes are encoded in some subset of ASCII but are much longer than ascii-encoded MD5 hashes. I cannot find the code in Darwin where this is done, assuming this was publically released (which it definitely should be). I'm very curious and google turns up nothing, so if anyone knows, I would appreciate it.
Actually to compare a value to a crypt()ed value you can't just pass the hash because you don't know in advance what salt was used to create the hash. In all these cases the plain password is probably sent instead...
In standard crypt() format, the salt is the first two characters of the hash.
The characters "xo" are chosen at random when the password is first hashed. Note how they are the first two characters of the hash. The canonical way to check if a given password matches a hash is:
% perl $hash = "xoqGBOjl8JQ8I"; $pass = "hello"; print "they match\n" if $hash eq crypt($pass, $hash); they match
Note how I use the entire hash as the salt. Only the first two characters of the salt are actually used by crypt(). Actually, only twelve bits from the first two characters are used for the salt:
Two different salts resulted in the same hashes: this shows that crypt() does not use the entire 16 bits of the two characters (indeed, not even the entire 14 bits of the characters as US-ASCII). Only twelve bits are in fact used.
Also, the entire password is not used: in fact, only the first eight characters of the password are used:
Since slashcode strips un-american characters, I cannot demonstrate the the top bit of each character in the passphrase is discarded.
Now, we can do some math: if 12 bits of salt is used, we have 4096 possible salts (2 ^ 12). If 7 bits of 8 characters are used, we have 7 * 8 = 56 bits of possible password. Thus, we have 2 ^ 56 * 4096 = 295147905179352825856 possible passwords (295 quintillion).
Now, these numbers don't match up with what's reported in the article description (207 billion hashes). It's possible that some combinations of passwords and salts produce identical hashes, but I would never expect nearly this many...time to read the article.
OK, I skimmed the article. They did not cover the entire keyspace of passwords. They only created a list of candidate passwords from a system dictionary using Crack's password generation routines. There are 1425835290 (1.4 billion) times more possible passwords than they tested. If they tried hashing all possible passwords, it would have taken them 217022 years at the rate they're going (80 minutes per 207 billion passwords). The storage of these hashes is out of the question (I don't know my metrics that high:).
Actually, on second thought, I can imagine a compression scheme that could drastically cut down on the storage involved: but this is irrelevant, the CPU time is still overwhelming.
Lesson learned: worry more about the quality of your passwords than the quality of your password hashing algorithm.
[Perhaps I missed something? Anyone care to check my arithmetic?]
In Panther (10.3+) it will not show the hashes, and I believe a different algorythm is used anyway.
In 10.3, the netinfo entries contain a reference to a file and this file contains the hashed password. Of course, the file is readable only by root. I was pretty vocal about this problem so I'm glad to see it fixed. Each user has their hash stored in a separate file, which I guess could be useful. At least it cuts down on pointless parsing.
The hash algorithm used is apparently MD5, but they don't store the hashes in the usual textual MD5 representation. I guess they really hate parsing.
Even more fun was if you used netinfo for network authentication, all hashes for all users on the network were available to the world, not just authenticated users. This meant you had to restrict access to your netinfo server to an IP range to avoid advertising your hashes to the Internet. Thankfully they started deprecating netinfo network authentication in 10.2, but this was recommended practice with 10.1 Server.
Sorry, a UN managed internet would simply give certain 3rd world countries (and some European) a new means to bash or otherwise attempt to restrict prospering Western countries. It would advance anti-Jewish attitudes, probably going as far as to restrict Israel! China would be given free reign to threaten Tiawan and run ramshackle over tibet. Can you imagine what these nations would want to classify as SPAM?
Sorry, but am I the only one who identifies this as flaimbait?
What gives occidental countries a greater right to speech over other cultures? The West may have the power to impose their views upon others, but does this power legitimize imposing their views?
Consider the example of the WIPO, which is controlled by western countries. Western ideas of "intellectual property" are forced upon African and Asian countries, meaning they cannot produce medications for their own people, but have to buy medication from Western corporations at artificially-inflated prices. Had these smaller nations not been strong-armed into signing agreements on intellectual property, they would have been able to afford medication for their people.
This phrase strikes me as particularly frightening:
It would advance anti-Jewish attitudes, probably going as far as to restrict Israel!
Have you not considered that perhaps Israel should be restricted, as with all other governments of the world? Israel (one of the world's worst human-rights violators), is subject to the same international laws as other countries. These laws are agreed upon at international conferences such as the one proposed, and these conferences should receive participants from all manner of nations, even those that believe Israel illegitimate.
It is, of course, easier to sign an agreement than to enforce it, so these agreements are regularly disregarded by the most powerful nations (Israel declaring that the Geneva convention does not apply to suspected terrorists, the US inventing the term "illegal combattant" to circumvent international law regarding prisoners of war), but the first step to ensuring that all nations are held responsible for their actions is unilateraly agreeing upon standards to uphold.
At first, I agreed that no useful regulation can come of this summit and that the Internet should remain absolutely unregulated. However, while formulating this post, I begin to see what "restrictions" against Israel you may fear. Whereas in the US computer crime is performed mostly by harmless vandals and warez groups, in the Middle East network attacks are often motivated by politics. What international law stops the Mossad from attacking the network infrastructure of an opposing political group or funding vandals to deface opposition websites? At the moment, no such agreement exists.
If this conference forces powerful nations to listen to the viewpoints of the rest of the world, some good may come of it.
Do you have any idea how OS/X does "aliases"? It appears that open() works for them.
I think you're right. I tried it on an up-to-date 10.3 installation running HFS. If I write a small test program, I can open read/write, write to the file, close it and the file contains data and is still an alias (although the alias is not dereferenced on open()). I can also rename() the file and it continues being an alias. This doesn't really indicate whether or not there's kernel code that deals with aliases, as a rename only changes a directory entry and does not mess with inodes. The actual alias resolution stuff could still be done in userland, but I can't find any information on it.
I think my confusion arose because I tried "vi alias" and it's likely vi writes the data to a new file and renames it to the original filename, to preserve atomicity.
I like lots of things about OS X, but the one thing I really don't like at all is how it handles file forks. Recently, OS X introduced a syntax where you can get to a file's named fork with a syntax like "filename/..namedFork/rsrc". Previously, it used a syntax like "filename/rsrc" (which still works). I heard somewhere that ReiserFS is experimenting with named forks and is using the same syntax, so this may become a de-facto standard (don't know who came up with the syntax first). I don't think the syntax is really bad since it means one can manipulate forks using standard Unix stuff, but since these are really pseudo-directories, they're not very "discoverable" - you have to explicitly open() to look for them. This means that you cannot, for instance, tar up a directory tree and expect the forks to remain. This in turn means that a lot of Unix stuff has to be rewritten to play nice with OS X; for instance, OS X supplies the standard version of rsync that knows nothing about forks, but there is another version of rsync out there that knows about them. I think the best way to deal with forks is how OS X does them on UFS file systems - they are stored in separate dot files and directories along with the files. Both systems break when you're not careful with "mv"; both systems work when you are in the position that you can use a non-standard tool like "ditto" or some custom script; but the UFS way still works when you're semi-careful with standard tools like tar. Strangely enough, the UFS dot-files still work on HFS systems and at one point I wrote a script to convert an HFS hierarchy with forks to use UFS dot-files.
Since this "..namedFork" syntax works through a system call and doesn't really dereference directory entries, there would likely be some code in the kernel that parses it.
Regarding ideas about merging hard links and symlinks: this could be useful, but I don't see why we can't also add a volume identifer as well. The real problem I see with hard links is that they break across volumes and adding a volume identifier would remove a limitation without adding any incompatibilities as far as I can see.
This could even be considered a feature, not a bug?
It would be a feature in some circumstances, and a bug in others. For instance, I usually organize software by maintaining a symlink to the "current" version of the software. For a concrete example: OS X has a "simple finder" interface which is moderately useful for custom kiosk-type applications. I was using this and the machine was running basically one custom program. The program is started at login and made accessible to the user by placing an alias in a certain directory, something like "~/Library/ManagedItems" . When I upgrade the application, I do "mv/Applications/Custom.app/Applications/Custom.app.old" and create a new/Applications/Custom.app. However, the alias still points to the old version of the application and I was expecting symlink behaviour, so I did not discover this right away on a particular machine. The UI automatically set up aliases and I was able to
The trick is that either the kernel or libc is modified so open() will detect this and instead open the linked file. In fact I'm not sure where Linux does these, it may be libc.
Absolutely not. You know that there are indeed programs that do not use libc, even in Linux? Unix programmers (usually) do not resort to these sort of shenanigans. You are correct in that the KDE/GNOME vfs folks are going in the wrong direction. The things they are doing should be done in a system-wide way, but mp3-ripping code does not belong in the kernel, rather in userspace. Linux has some experimental userspace filesystem stuff, but not BSD/Solaris/etc. which KDE/GNOME also support. The correct solution would be to have this built into the system from the start, like plan9 does it.
NT does it completely wrong in that the documentation for this stuff ("installable filesystems") is only available coughing up $1000 (and very likely signing an NDA). Projects like ext2 for NT are based on a lot of reverse-engineering.
I believe otherwise hard links are useless and can be replaced with soft links, any persistant hard links are just confusing.
I give a short quiz to every person I interview for a position. One is "demonstrate a reasonable use for a hard link." Possible examples:
1. A certain program runs in a chroot environment. The only way to give this program open() access to files outside its the chroot environment is through hard links.
2. You are making a rescue disk or a flash-based router which uses busybox and is extremely limited on disk space and inodes. Hard links do not use inodes but only directory entries.
3. You have a third-party proprietary program that checks if a file is a symlink and you want it to use a symlink.
4. You have a third-party proprietary program and you wish to bypass its locking semantics. For example, VMWare for Linux will lock a virtual disk file and the utility for mounting this virtual disk host-side also attempts to lock the file. I needed to bypass this locking (I knew what I was doing, it's my data) and was able to do it in a couple seconds with a hard link, whereas I would have to hack libc or the kernel to do it without hard links.
I name these four things as these are the things I've done with hard links at some point or another. Some interviewees came up with original and creative responses.
For an example of a number of these ideas used together, read about snapshots with rsync.
You mention atomic renames, but Unix provides atomic rename(2) functionality (NB: (2), not (3)). I'm not sure how renaming with hard links would really very useful because if the system crashes between link() and unlink(), you end up with two links, so this isn't really atomic.
Mac OS/9 "semi-soft links" sound very interesting, but they do need significant changes to Unix file systems.
MacOS "aliases" are basically hard links that work across devices. The alias contains a file number (akin to an inode number) and a volume number. If the original file is moved from one volume to another, the alias fails. No path information is recorded in the alias file, so there is no fall back to symlink behaviour when the original file is moved to a different volume. All the information is recorded in the resource fork and the alias file has an "isalias" bit in the Finder fork.
In MacOS 9, aliases are handled by the Finder and the standard file-open dialog, although there are alias APIs for applications. MacOS 9 was very strange in that programs very rarely opened files themselves, but rather opened files only via user interaction (double-click in Finder, open dialog or drag-and-drop). If you tried to access a file's resources directly without first checking if the file is an alias (and resolving the alias), you might get garbage (accessing the file's data gives you an empty file); obviously, th
I can't think of a modern system that doesn't support long passwords.
The Solaris getpass() function only returns the first eight characters of the password read. This, combined with the fact that much of Solaris still uses getpass(2) (such as/bin/login), means that Solaris passwords are limited to eight characters, and the passwd(1) command enforces this limit to ensure hashes are getpass-friendly.
If someone gets to your physical machine and wants to own it... they can.
I don't think that's the real problem. If I leave my laptop unattended, I fully expect it to get "owned", literally and figuratively.
I sometimes do presentations with my powerbook (not powerpoint, thank you very much, but software demonstrations). I type very fast and can type most of my password in the time interval it takes to fade out the screensaver. If I had to wake my laptop from a screensaver in front of an audience - that would be bad.
I'm the soul-less who despises frills such as screensavers, so it doesn't affect me, but it's still a nasty hole.
Slashdot Mirror
Sure. Commercial software always uses version numbers to indicate minor and major changes, whereas open source software uses version numbers willy-nilly.
Let's look at Sun for example. Long ago, we had SunOS 4.0. This continued until Sun was ready for the next major version of their OS. Instead of calling it SunOS 5.0, they created a new product line and called it Solaris 2.0. To stem confusion, the older versions of SunOS were re-branded with the Solaris moniker, so that Solaris 1.4 was equivalent to SunOS 4.4 and Solaris 1.3 was equivalent to SunOS 4.3, and so on. Thus, managers could easily see that they needed to upgrade if they were told that they were running Solaris 1.4 instead of 2.0, whereas SunOS 4.4 versus Solaris 2.0 was simply too confusing. To further help decision-makers, Solaris 2.7 was also named Solaris 7.0, in addition to SunOS 5.7 and Solaris 9.0 is also known as Solaris 2.9 or SunOS 5.9. This continues until today where IT managers can easily see if they need to upgrade by converting the new Solaris number into the old Solaris number for machines running versions of Solaris greater than 7.0 and converting SunOS numbers into old Solaris numbers.
So anyone can clearly see that commercial software vendors use versioning in order to minimize confusion among users.
On the other hand, open source developers are continually inflating version numbers in order to compete with other open source developers for precious clients. For examples, one has to look no further than the Linux even-stable/odd-development scheme or FreeBSD's branches. Obviously these developers are only attempting to confuse users through versioning in order to increase sales.
In addition, many open source efforts are constrained by the vagaries of their marketing departments. For example, Knuth's TeX approaches pi with each new version. Obviously, this was a shrewd tactic on the part of his marketing people to entice those mathematically-inclined (and how successful it was!).
When you call realloc, you're very likely to cause the data to be copied from the old buffer to the new buffer. This is very high overhead. The article discusses how to do similar things, but without this unecessary copying (eg, low overhead). It's actually not that interesting of an article as what it describes is hardly new and I believe any competent programmer could come up with that solution when faced with the particular circumstances that inspired it.
Realloc works by seeing if there is free memory after the end of the allocated block, and changing the block's size if so. Realloc can do this because it knows about the internals of the malloc/free implementation. If there is allocated memory right after the block in question, a new block must be allocated, as you cannot "move" the later block in a language like C where any memory location can be a pointer. You could try this kind of stuff in other languages (or in some bastardized C where you do not have direct access to memory, but go through more indirection, the next logical abstraction after the article), but when you start automatically finding/checking/updating memory pointers, you get into GC.
You may be able to overcome some overhead on realloc if you move the problem down into the kernel. The kernel could play page table games so there is little or no actual copying involved, just updating of page tables. This would be fairly easy to implement, but I don't think anyone's done it because (a) flushing the relevant TLB entries could hurt performance more than the copying, and (b) the system call overhead might be more overhead than the copying. Realloc is generally only used for small buffers (due to programmers knowing about the copying overhead) and this trick would only have gains for large buffers spanning multiple pages. For small buffers, the library-level realloc could avoid the system call and do the copying itself, avoiding system call overhead and TLB entry flushes.
This scheme I describe could make for an interesting paper (especially determining for what size of buffer and what type of program it has gains), but I doubt it would make much difference in real system performance as programmers avoid realloc for large buffers, and there are very few cases where one needs direct linear access to a large range of memory rather than being better-served by organizing that memory into some data structure.
A member of our IT department did a report on exactly this about a year ago. I don't have the report with me, but I can dig up details if required. The laser printers we evaluated were high-end workgroup printers and we took all costs into consideration (initial investment, rollers, maintenance kits, labor (whether we have an in-house technician or contract out the maintenance)).
We also used more realistic estimates on toner/ink usage than the industry defines. The standard industry test for toner cartridge life is at 5% coverage: they have a standard letter they send through the printer multiple times to see how long toner lasts. I wrote the print server software we use and for a few months I calculated and kept logs of ink coverage (on spare CPU cycles, render pages from postscript using printer's DPI and count pixels based on a gray-level heuristic that makes the standard test page come out at 5%). In (what I would call) a normal office environment, our coverage was around 8%, significantly higher than the "industry standard." There are lots of variables here, but the numbers we got for coverage roughly matched how much toner we actually purchased versus pagecount (also logged systematically). As such, I would not put much faith into the numbers printer manufacturers give you. The cartridges we buy are either refilled or we get a good enough volume deal on OEM cartridges that they cost the same as refilled.
Anyway, end results:
Laser: circa $0.07 / page
Inkjet: circa $0.25 / page
The inkjets costs were driven that high not just by cost of ink, but by cost of initial investment and maintenance. We usually have a lifecycle of at least four years on our laser printers in a high volume environment, but our investigations turned up the the average lifecycle of a personal inkjet is about two years. Also important is that most inkjets are simply thrown away when there is something wrong with them but laserjets like the ones we use are repaired and eventually retired to lower-volume environments, but rarely scrapped.
If you're looking at a personal laser printer instead of higher-end workgroup stuff the difference will of course fall (similarly to how the difference would grow if you're looking at professional print-shop stuff), but I'm pretty sure the savings would still be significant. As for myself, I don't own a printer - I just print my personal stuff after-hours at work :)
I guess you're looking for a hardware player, but mplayer will just play the movie without forcing you to go through menus, legal warnings, etc.
Let me ask you this: how can you restrict privileges to the RPCSS service?
Well?
I'm still waiting for an answer.
The answer is that you cannot restrict privileges to the RPCSS service. It must run as SYSTEM, the NT equivalent of root. Although ACLs can be applied to the SYSTEM account, they can be bypassed easily as SYSTEM can insert code to run at IA32 ring zero.
Let us then see how many services run by default under the SYSTEM account in a Windows machine: well, that's all of them, isn't it?
Why don't we try a little experiment. Lets take a ridiculously trivial service, one that can be written in minutes: the Messenger service.
Now let's take Messenger and run it under a different account so we can apply access controls to it. What does it do?
Well, now what does this mean? Perhaps I did not give the Messenger service a privileged enough account? Nope. Perhaps I need to restart the computer rather than starting the service directly? Nope.
The problem is that Messenger runs as a thread under svchost.exe, as it is an RPC service "built into" the various other crap there. Is this a fine-grained security model?
Note also that when you attempt to have a service start under different credentials (should you ever attempt this as I very seldom see it), you must type the account's password. Perhaps this is a security feature so that one cannot install a service which then grants the user elevated privileges? Nope.
In order to change credentials in NT ("obtain a security token"), you must supply the account's password. When you have a service run under a different account, that password that you type in is saved somewhere as it must be supplied in order to obtain different credentials. Where is it saved? Beats me. How is it stored? Probably "encrypted" using some machine-specific information; however, it must be decrypted upon launch of the service, so the password must be recoverable (without undue computation, eg, it is not hashed).
Linux system administrators must spend huge amounts of time understanding the latest Linux bugs and determining what to do about them.
...
Configuring Linux security requires an administrator to be an expert in the intricacies of the operating system and how components interact.
Again, let me pose a question to you, as I assume you see yourself as a competent NT administrator:
How do you disable DCOM without restricting RPC? You cannot consult google, but must discover the answer on your own.
Obvious response: firewall.
Well, a firewall isn't the answer. Say box X needs to talk to box Y using DCE RPC. You cannot insert any firewall I know of between X and Y which stops DCOM but allows through other RPC programs as no firewall I know of works at this level of the stack. You could perhaps put something like a snort box in between X and Y that allows for user-programmable packet inspection, but please don't tell me that's "easy to set up and administer".
Correct response is documented here. But a competent NT administrator such as you knew that, of course.
Let's tackle the equivalent problem on a Unix machine: we have an RPC service that we want to disable. Well, which one do we want to disable? NFS? Stop nfsd from launching. YP? Stop ypbind from launching. Mountd? Stop mountd from launching. You get the idea.
How do you stop a daemon from launching? Tru
What I want to know is how much of the backend stuff they've changed. For instance, if they've upgraded gcc. It doesn't really affect me if the front end breaks, but I have a largish project which I'm right now preparing for release and I need to decide whether to build now or to run the update and go through another testing cycle. My intuition tells me to build now and update later, but I don't know if they've fixed any massive compiler bugs.
No, Windows doesn't have setuid executables, but if it did that would be a quick fix to his problem. The "run as different user" feature prompts the user for the target account's password before running. The proper solution would be to give the account access to read those non-filesystem sectors on the CD, but I have no idea what API games use to implement this.
It also may be difficult to reimplement the "run as" feature so it does not ask for a password. Windows does not have any equivalent to a "setuid" system call: to change a program's credentials, one must provide a password. You can see this when you try to run a service under a different account: it will prompt you for the target account's password if you don't have the service run under SYSTEM (svchost runs under SYSTEM (the real equivalent to root, more privileged than administrators), so services don't need a password to run under that account). This password is then saved somewhere (not sure where or how, but the calls require plaintext passwords so it must be recoverable). When Windows apologists claim that the Windows security architecture is well-designed but it only has been tainted by backwards-compatibility, this is one of the examples I use to refute their claims.
It may be possible to build an executable that has an administrator password built into it. The idea is that you have a service (running as SYSTEM) and then a small program that communicates with the service and asks it to launch an executable. The service has the password built into it (or stored somewhere), so the user is never prompted for a password. Or equivalently, the service runs under the target account and you let Windows save the password for you (presumably, Windows will somehow obscure the password). Obviously, this makes the password available in cleartext to available to anyone who can boot off a Linux floppy and bypass filesystem controls, but I'm guessing you're not worried about your kids doing this.
Writing such a service is very non-trivial. The security APIs it uses are very poorly documented and you have to go through all kinds of loops to allow a service to interact with the user's desktop (necessary for the spawned game process). This stuff is so horrid that I don't touch it without getting paid, but I'm available for consulting work if it's that important to anyone :)
I do not want your spam for sure. ....
.procmailrc,
I like my mortgage and what's more -
I do not want your stinking toner
or to enlarge my ample
Your open relays cause me pain;
I swear that they'll drive us insane.
One day we'll lose it, wait and see,
And then you'll beg, "Oh no, not me!"
While you bloat my
we check your whois, oh, tee-hee!
A traceroute takes this to your door:
some hits you've never seen before.
We take your name; we find your home.
What's this? A Navy ship with chrome?
A hearty vessel, nonetheless
we send it a DDoS.
And now with us, your greatest foe,
you'll need your San Antonio.
Your Navy admins (what a lot!)
won't help you to survive Slashdot.
Now later, when the smoke has cleared,
your website, it has disappeared!
Because you let some spam relay,
Slashdotting is your world today.
cat /dev/sda1 | cdrecord
UUOC. Instead,
Well, if you're worried about running the code, I can tell you what it does: it will give you a parse error, as I included square brackets where I shouldn't have. Since nobody has yet noticed the syntax error and since all three lines of the script were 100% open source, I'm forced to assume that this is a failure of the open source code review model.
I'll be sure to include a pgp signature the next time I post a one-liner.
Your kernel is being asked to execute some binary whose first two bytes are 498B. This is a binary file but not an ELF executable; it seems likely that some program is attempting to exec a random binary data file or you have some filesystem corruption. Errno 8 is ENOEXEC, file is not a recognized executable format. You can track it down with something like this:
Save that asNow, will someone on Slashdot buy me an iPod?
I've been doing this for over five years and my "real" address has (thank goodness) never got out (I only give it to humans). Over the course of five years, I've only accumulated about twenty or thirty procmail rules to discard mail to addresses that have been sold or leaked (most often via lax policy on someone else's website where large numbers of user addresses were posted). I also threw together an emacs lisp hack for gnus that automatically generates a new address whenever I post to usenet. I get literally zero spam and I never worry about legitimate mail not getting through.
For those who think having a vanity domain and mucking with sendmail is not worth it - there are other ways to do this. I believe sendmail's defaults allow you to send mail to "account+foo@example.com" where foo is any arbitrary string. I know for certain that qmail allows you to send mail to account-foo@example.com out of the box.
I'm so happy with this setup that whenever a spam-related story comes up on Slashdot, I post this same information. Gotta share the love.
This is incorrect. It is indeed possible to determine how an arbitrary program will function by looking at and analyzing the code. Rather, the Halting Problem states that it is impossible to write a program that will make this determination.
The Halting Problem has nothing to do with the execution environment (compiler, OS, hardware, etc). The idea that you cannot trust software because of the execution environment was popularized by Brian Kernighan.
WARNING: SPOILER - the Halting Problem is interesting enough that it should be studied in proper context (in a Complexity class), and not from me, who may fubar it up.
The Halting Problem works on Turing Machines, which are a simplified model of computation, but provably equivalent to most other reasonable models of computation. You can think of a Turing machine as a software function/subroutine or a hardware machine, but that does not change what it can compute (they were originally described as mechanical devices - there were no electronic computers at that time). It is very tedious to write Turing machines but they can be analyzed with a level of mathematical rigor not feasible with modern programming languages, or even assembly languages. The relevant properties of Turing machines is that a Turing Machine M is given input A before starting. M may do one of two things: it may halt or it may loop forever. If M halts, it will output an answer, a binary yes or no.
The Halting Problem states:
It is impossible to writing a Turing machine "HALTS(M, A)" which on input (M, A) halts with TRUE if M(A) halts and halts with FALSE if M(A) does not halt.
Proof:
Consider a new program FOO(M). FOO can be described as follows:
If HALTS(M, FOO) returns FALSE, then halt and return TRUE.
If HALTS(M, FOO) returns TRUE, then loop infinitely.
Does FOO(FOO) halt?
FOO can be described as a Turing machine and HALTS must be a Turing machine as well, so FOO is a perfectly valid Turing machine. However, FOO either leads to a contradiction or has unspecified behaviour, so some part of FOO must not be a valid Turing machine. The only unspecified part is the subroutine HALTS, so it must not be a valid Turing machine.
This does not mean that programs cannot be analyzed mathematically (and there are various techniques to do this, loop invariants being one real-world-applicable example), but it means that it is impossible to write programs that do certain things (that is, the Halting Problem helps define what's computable).
Imagine if Turing machines could ask for input from a human during their execution and you were the subroutine HALTS(M, A). What would you answer when asked HALTS(FOO, FOO)? I would answer that humans are not a reasonable model of computation :)
The following machines are running currently-reachable FTP servers:
216.250.128.7
216.250.128.13
216.250.128.14
216.250.128.15
216.250.128.16
216.250.128.17
I was able to download /pub/ls-lR from ftp.sco.com (216.250.128.13) 74.91 KB/s (600 Kb/s). My broadband is rated at 640 Kb/s, so the bottleneck was likely at my end. These machines are almost certainly on the same subnet and are likely connected to the same gear (SCO's subnetting is their choice, but if ftp.sco.com and www.sco.com are on different subnets, their subnet masks are 255.255.255.254 and they must have only two IPs per subnet - I don't believe this is even possible as you need a network and a broadcast IP for each subnet).
The fact that all of these machines are reachable and that at least one of them can saturate a broadband link indicates that SCO is not having any bandwidth problems. I also performed some ICMP tests and the machine is not sending out port-unreachables, timestamp-replies or netmask-replies - these seem blocked upstream. I'm getting a little nervous sending out these funny packets as I don't want anyone to accuse me of anything, but everything indicates that the machine is completely offline. If they allowed some ICMP replies through upstream, receiving a reply would show that the machine is actually online, but somehow cannot handle TCP requests (and the problem is not bandwidth as shown, so it would have to be something wrong with the host, such as a firewall rule); if they allowed through ICMP replies and the machine did not respond whereas others on the subnet did respond, it would show that the machine is almost definitely offline unless it has a more restrictive firewall than the other machines (very unlikely given that this, as-claimed, could have been prevented with syncookies). As it stands, one can only say that the machine is very likely offline (unplugged or turned off).
SCO's incoming mail server seems to be working fine. They only have one MX record for sco.com and it resolves to 216.250.130.2 for me at the moment. I only connected to it and saw a banner, but easy way to test this further is to send a message to an invalid address @sco.com and see if a bounce gets back. I don't want to give them an email address.
All of this is current as of 2003-12-10 21:57, Mountain time (SCO is in Utah). Further investigation lead nowhere; thus the delay in the post.
The adjective meaning "from or having to do with China" is spelt Chinese, not Chineese. SilentSage (original poster) got it wrong (consistently) and now this new word is propagating. Posting history would indicate that SilentSage is American and you are Canadian. Sic transit gloria mundi.
Correction: the hash algorithm is not MD5. I heard someone mention MD5 and assumed they were correct without checking, but the hashes are actually much longer than MD5. The hashes are encoded in some subset of ASCII but are much longer than ascii-encoded MD5 hashes. I cannot find the code in Darwin where this is done, assuming this was publically released (which it definitely should be). I'm very curious and google turns up nothing, so if anyone knows, I would appreciate it.
In standard crypt() format, the salt is the first two characters of the hash.
The canonical way hash a password using crypt():
The characters "xo" are chosen at random when the password is first hashed. Note how they are the first two characters of the hash. The canonical way to check if a given password matches a hash is:Note how I use the entire hash as the salt. Only the first two characters of the salt are actually used by crypt(). Actually, only twelve bits from the first two characters are used for the salt: Two different salts resulted in the same hashes: this shows that crypt() does not use the entire 16 bits of the two characters (indeed, not even the entire 14 bits of the characters as US-ASCII). Only twelve bits are in fact used.Also, the entire password is not used: in fact, only the first eight characters of the password are used:
Since slashcode strips un-american characters, I cannot demonstrate the the top bit of each character in the passphrase is discarded.
Now, we can do some math: if 12 bits of salt is used, we have 4096 possible salts (2 ^ 12). If 7 bits of 8 characters are used, we have 7 * 8 = 56 bits of possible password. Thus, we have 2 ^ 56 * 4096 = 295147905179352825856 possible passwords (295 quintillion).
Now, these numbers don't match up with what's reported in the article description (207 billion hashes). It's possible that some combinations of passwords and salts produce identical hashes, but I would never expect nearly this many...time to read the article.
OK, I skimmed the article. They did not cover the entire keyspace of passwords. They only created a list of candidate passwords from a system dictionary using Crack's password generation routines. There are 1425835290 (1.4 billion) times more possible passwords than they tested. If they tried hashing all possible passwords, it would have taken them 217022 years at the rate they're going (80 minutes per 207 billion passwords). The storage of these hashes is out of the question (I don't know my metrics that high :).
Actually, on second thought, I can imagine a compression scheme that could drastically cut down on the storage involved: but this is irrelevant, the CPU time is still overwhelming.
Lesson learned: worry more about the quality of your passwords than the quality of your password hashing algorithm.
[Perhaps I missed something? Anyone care to check my arithmetic?]
In Panther (10.3+) it will not show the hashes, and I believe a different algorythm is used anyway.
In 10.3, the netinfo entries contain a reference to a file and this file contains the hashed password. Of course, the file is readable only by root. I was pretty vocal about this problem so I'm glad to see it fixed. Each user has their hash stored in a separate file, which I guess could be useful. At least it cuts down on pointless parsing.
The hash algorithm used is apparently MD5, but they don't store the hashes in the usual textual MD5 representation. I guess they really hate parsing.
Even more fun was if you used netinfo for network authentication, all hashes for all users on the network were available to the world, not just authenticated users. This meant you had to restrict access to your netinfo server to an IP range to avoid advertising your hashes to the Internet. Thankfully they started deprecating netinfo network authentication in 10.2, but this was recommended practice with 10.1 Server.
Sorry, but am I the only one who identifies this as flaimbait?
What gives occidental countries a greater right to speech over other cultures? The West may have the power to impose their views upon others, but does this power legitimize imposing their views?
Consider the example of the WIPO, which is controlled by western countries. Western ideas of "intellectual property" are forced upon African and Asian countries, meaning they cannot produce medications for their own people, but have to buy medication from Western corporations at artificially-inflated prices. Had these smaller nations not been strong-armed into signing agreements on intellectual property, they would have been able to afford medication for their people.
This phrase strikes me as particularly frightening:
It would advance anti-Jewish attitudes, probably going as far as to restrict Israel!
Have you not considered that perhaps Israel should be restricted, as with all other governments of the world? Israel (one of the world's worst human-rights violators), is subject to the same international laws as other countries. These laws are agreed upon at international conferences such as the one proposed, and these conferences should receive participants from all manner of nations, even those that believe Israel illegitimate.
It is, of course, easier to sign an agreement than to enforce it, so these agreements are regularly disregarded by the most powerful nations (Israel declaring that the Geneva convention does not apply to suspected terrorists, the US inventing the term "illegal combattant" to circumvent international law regarding prisoners of war), but the first step to ensuring that all nations are held responsible for their actions is unilateraly agreeing upon standards to uphold.
At first, I agreed that no useful regulation can come of this summit and that the Internet should remain absolutely unregulated. However, while formulating this post, I begin to see what "restrictions" against Israel you may fear. Whereas in the US computer crime is performed mostly by harmless vandals and warez groups, in the Middle East network attacks are often motivated by politics. What international law stops the Mossad from attacking the network infrastructure of an opposing political group or funding vandals to deface opposition websites? At the moment, no such agreement exists.
If this conference forces powerful nations to listen to the viewpoints of the rest of the world, some good may come of it.
I also play music on my Zaurus. Might I suggest: get a big SD card. That way, you leave the CF slot open for peripherals like wifi cards.
I think you're right. I tried it on an up-to-date 10.3 installation running HFS. If I write a small test program, I can open read/write, write to the file, close it and the file contains data and is still an alias (although the alias is not dereferenced on open()). I can also rename() the file and it continues being an alias. This doesn't really indicate whether or not there's kernel code that deals with aliases, as a rename only changes a directory entry and does not mess with inodes. The actual alias resolution stuff could still be done in userland, but I can't find any information on it.
I think my confusion arose because I tried "vi alias" and it's likely vi writes the data to a new file and renames it to the original filename, to preserve atomicity.
I like lots of things about OS X, but the one thing I really don't like at all is how it handles file forks. Recently, OS X introduced a syntax where you can get to a file's named fork with a syntax like "filename/..namedFork/rsrc". Previously, it used a syntax like "filename/rsrc" (which still works). I heard somewhere that ReiserFS is experimenting with named forks and is using the same syntax, so this may become a de-facto standard (don't know who came up with the syntax first). I don't think the syntax is really bad since it means one can manipulate forks using standard Unix stuff, but since these are really pseudo-directories, they're not very "discoverable" - you have to explicitly open() to look for them. This means that you cannot, for instance, tar up a directory tree and expect the forks to remain. This in turn means that a lot of Unix stuff has to be rewritten to play nice with OS X; for instance, OS X supplies the standard version of rsync that knows nothing about forks, but there is another version of rsync out there that knows about them. I think the best way to deal with forks is how OS X does them on UFS file systems - they are stored in separate dot files and directories along with the files. Both systems break when you're not careful with "mv"; both systems work when you are in the position that you can use a non-standard tool like "ditto" or some custom script; but the UFS way still works when you're semi-careful with standard tools like tar. Strangely enough, the UFS dot-files still work on HFS systems and at one point I wrote a script to convert an HFS hierarchy with forks to use UFS dot-files.
Since this "..namedFork" syntax works through a system call and doesn't really dereference directory entries, there would likely be some code in the kernel that parses it.
Regarding ideas about merging hard links and symlinks: this could be useful, but I don't see why we can't also add a volume identifer as well. The real problem I see with hard links is that they break across volumes and adding a volume identifier would remove a limitation without adding any incompatibilities as far as I can see.
This could even be considered a feature, not a bug?
It would be a feature in some circumstances, and a bug in others. For instance, I usually organize software by maintaining a symlink to the "current" version of the software. For a concrete example: OS X has a "simple finder" interface which is moderately useful for custom kiosk-type applications. I was using this and the machine was running basically one custom program. The program is started at login and made accessible to the user by placing an alias in a certain directory, something like "~/Library/ManagedItems" . When I upgrade the application, I do "mv /Applications/Custom.app /Applications/Custom.app.old" and create a new /Applications/Custom.app. However, the alias still points to the old version of the application and I was expecting symlink behaviour, so I did not discover this right away on a particular machine. The UI automatically set up aliases and I was able to
Absolutely not. You know that there are indeed programs that do not use libc, even in Linux? Unix programmers (usually) do not resort to these sort of shenanigans. You are correct in that the KDE/GNOME vfs folks are going in the wrong direction. The things they are doing should be done in a system-wide way, but mp3-ripping code does not belong in the kernel, rather in userspace. Linux has some experimental userspace filesystem stuff, but not BSD/Solaris/etc. which KDE/GNOME also support. The correct solution would be to have this built into the system from the start, like plan9 does it.
NT does it completely wrong in that the documentation for this stuff ("installable filesystems") is only available coughing up $1000 (and very likely signing an NDA). Projects like ext2 for NT are based on a lot of reverse-engineering.
I believe otherwise hard links are useless and can be replaced with soft links, any persistant hard links are just confusing.
I give a short quiz to every person I interview for a position. One is "demonstrate a reasonable use for a hard link." Possible examples:
1. A certain program runs in a chroot environment. The only way to give this program open() access to files outside its the chroot environment is through hard links.
2. You are making a rescue disk or a flash-based router which uses busybox and is extremely limited on disk space and inodes. Hard links do not use inodes but only directory entries.
3. You have a third-party proprietary program that checks if a file is a symlink and you want it to use a symlink.
4. You have a third-party proprietary program and you wish to bypass its locking semantics. For example, VMWare for Linux will lock a virtual disk file and the utility for mounting this virtual disk host-side also attempts to lock the file. I needed to bypass this locking (I knew what I was doing, it's my data) and was able to do it in a couple seconds with a hard link, whereas I would have to hack libc or the kernel to do it without hard links.
I name these four things as these are the things I've done with hard links at some point or another. Some interviewees came up with original and creative responses.
For an example of a number of these ideas used together, read about snapshots with rsync.
You mention atomic renames, but Unix provides atomic rename(2) functionality (NB: (2), not (3)). I'm not sure how renaming with hard links would really very useful because if the system crashes between link() and unlink(), you end up with two links, so this isn't really atomic.
Mac OS/9 "semi-soft links" sound very interesting, but they do need significant changes to Unix file systems.
MacOS "aliases" are basically hard links that work across devices. The alias contains a file number (akin to an inode number) and a volume number. If the original file is moved from one volume to another, the alias fails. No path information is recorded in the alias file, so there is no fall back to symlink behaviour when the original file is moved to a different volume. All the information is recorded in the resource fork and the alias file has an "isalias" bit in the Finder fork.
In MacOS 9, aliases are handled by the Finder and the standard file-open dialog, although there are alias APIs for applications. MacOS 9 was very strange in that programs very rarely opened files themselves, but rather opened files only via user interaction (double-click in Finder, open dialog or drag-and-drop). If you tried to access a file's resources directly without first checking if the file is an alias (and resolving the alias), you might get garbage (accessing the file's data gives you an empty file); obviously, th
The Solaris getpass() function only returns the first eight characters of the password read. This, combined with the fact that much of Solaris still uses getpass(2) (such as /bin/login), means that Solaris passwords are limited to eight characters, and the passwd(1) command enforces this limit to ensure hashes are getpass-friendly.
So where am I supposed to download it from? Their download page only lists 3.1-rc3.1 and 3.2, not 3.3.5.
I don't think that's the real problem. If I leave my laptop unattended, I fully expect it to get "owned", literally and figuratively.
I sometimes do presentations with my powerbook (not powerpoint, thank you very much, but software demonstrations). I type very fast and can type most of my password in the time interval it takes to fade out the screensaver. If I had to wake my laptop from a screensaver in front of an audience - that would be bad.
I'm the soul-less who despises frills such as screensavers, so it doesn't affect me, but it's still a nasty hole.