Nobody has yet replied to this point (subtle, this is easy to miss unless you've worked with people).
This is because adsl-connect is probably not in your PATH (I'm guessing it's in/sbin or/usr/sbin). You can do a 'man bash', hit the '/' key, type in PATH and keep typing 'n' until you find the entry in the manual page explaining how PATH works.
Short story: type in the following:
su - which adsl-connect
Make sure to type in the dash in the 'su' command. The second command should tell you exactly where adsl-connect is, and you can go from there.
Well, you could have a script run at boot time to connect the adsl, or one that is set to run as root no matter who runs it.
OS X, like most unices, doesn't honor the set-uid bit for scripts.
I would just write a trivial C program and make that set-uid:
#include <unistd.h>
#define ADSL "/path/to/adsl-connect"
int main() { execl(ADSL, ADSL, NULL); return 1; }
On OS X, install dev tools, compile as "cc file.c -o my-script" and then "chmod 4755 my-script". You can then run it from a normal user shell and the script is run as root (make sure the file is owned by root).
NB: I'm not replying directly to you, but rather to the original poster who wanted to know how to do this.
I am aware of Konqueror; the anecdote is still relevant. Even if you are now using GDM or KDM instead of XDM, those still create those authorization files and will not work if the file system is full.
Please, actually work with these people before trying to tell me how it would be so easy to convert them to unix. It's completely different in a corporate environment than the home environment (and I don't see OS X being targetted at corporate environments, so we're talking about mom and pop and their home computer here). In a corporate environment, they have you to get the machine working and install new software, etc. You try to put unix in a mom-and-pop home environment, and you'll be inundated with phone calls. You'll fix something for them (which will require root privs) and then you'll get another phone call 20 minutes later.
Try installing a mozilla build without using a command line, logged in as a regular user. Sure, you just install it to your home directory, but how many people are going to figure out that they need to change the default value in the dialog box? After you've installed it to your home directory, how do you start it up? Well, maybe it installed an icon on your KDE/GNOME desktop, maybe not. Let's assume it has. Now, what if you're in Konqueror and you want to use the "Open using Mozilla" menu option. Do you think that will work? Nope. Mozilla is not in your PATH (and that is what the latest version of Konqueror uses - it just does an execvp). Do you walk your grandmother through editing her.bashrc using emacs?
These people don't know the difference between a slash and a backslash - you'll have difficulties telling them over the telephone exactly which characters to type in, one at a time. When I say "et-see are see dot dee init dot dee" you think "/etc/rc.d/init.d" but mom-and-pop thinks "WTF?"
You'll then give up, go to their physical location, enable ssh, and fix everything remotely from then on.
I have a lot of patience - I regularly deal with intelligent non-computer people (I have a real job, you see) and I've very good at explaining technical matters to non-technical people, but dealing with this audience is a completely different matter - you will become frustrated sooner or later.
It's not really a matter of patience, but a matter of communication. When filesystem permissions and the simple relationship between users and groups doesn't make sense to someone, you simply don't have a common vocabulary to communicate expediently.
They will log in as root no matter what you tell them. Ask yourself how many people are running Windows 2000/XP on their laptops and how many of those people bothered to create a non-Administrator account.
I knew this physics guy that bought a Linux box so he could do his Fortran numerical analysis on his own, without relying on the insanely big, fast and reliable physics servers (go figure). Smart physics guy, complete unix newbie.
I'll only tell you the anectdote salient to this article. He would, of course, only log in as root as the KDE rpm front-end wouldn't work when you're logged in as a regular user and he didn't want to figure out how to use the the command-line rpm (I don't know if currently KDE does a sudo/su-type thing using the GUI, but it didn't back then - if you ran kfm as non-root, you couldn't use the RPM front-end).
At one point he could no longer log in. Problem? / was full. He was downloading all his stuff into/root (a one gig partition) and/home (20 gig partition) was completely empty. You could log in from console, but not from XDM since XDM creates files in/tmp upon login. He had no idea how to get from XDM to another virtual console, so he was effectively locked out of his machine.
My point? Give up. Don't worry about it. They will not learn why logging in as root is bad until they get burned. Especially since you're just a forum moderator - if you were getting paid to do this and your job depended on these machines staying up, you would have every responsibility to ensure people were properly following your policies; but, as a mere guru to these people, allow them to learn in the most effective fashion: trial by error.
You want to change all your.emacs,.exrc,.whatever to be world-readable so everyone can see just how clever you are:
chmod -R go+r.*
Well, not so clever after all. '.*' expands to include '..' and '.' and the -R flag combines with this in a Very Bad Way. I got burned by this once (different circumstances, however, I su'ed into root to change some stuff in/tmp). This also depends on what shell you use: with bash, you're screwed, with zsh, you're OK.
Years ago, my high school biology teacher liked to show this one film on Australian Cane Toads. Basically, these buggers were introduced intentionally in Australia to eat a particular kind of insect that was destroying crops. Problem was, these toads will eat anything, so they didn't go for the insects that would stay up high on the crops when they could eat anything else that crawled by.
They had a HUGE explosion of these things. This movie showed them in hoards. It also had this one scene with this hippie - the guy had a VW van and his hobby was to go around smashing these things. He would swerve the van from one side of the street to the other, running over the toads which would make a very satisfying pop. This hippie is the only thing I remember from high school biology.
So, my point is that these toads were introduced for an ecological reason (pest control), but apparently these guys didn't understand ecology all that well. Of course, this Hawaii thing is different since the frogs weren't introduced intentionally, but it seems toads/frogs have a talent for growing explosively.
Now, after
months of filing proposals, he has won a 4.5 million baht ($104,200) grant from
Thailand's National Research Council. The grant will help him finance a patent
with the World Intellectual Property Organization.
So, the guy could only get a patent after he received help from the government.
Now, let's read some more of the article:
With 2 million baht in savings he set up a small
factory in his provincial hometown of Chonburi. The factory can produce only
1,000-2,000 balls daily.
So, the guy used 2M baht in capital for starting his company, but he needs over twice that amount to get a patent.
[Regarding the atrocious English on the web page] This is the same kind of sloppy work
that causes cars to explode, missiles to veer off course,
More has been screwed up on the battlefield and misunderstood in
the Pentagon because of a lack of understanding of the English
language than any other single factor.
attributed to Gen John W Vessey Jr, US Army, Chairman, Joint Chiefs of Staff
Another possibility is to always have two overlapping time ranges.
Yes, upon further thought, I realized that this would be necessary. Another couple of problems that I came up with while thinking about it:
Suppose the linking site really wants to deep-link and the guy writing the linking site is technically capable. Now, instead of having a static HTML page or whatever, he could have a webcrawler that fetches the page every hour and publishes that URL. The webcrawler would have to go to your site's front page and walk the link tree down from there until it finds the correct page.
Couple of things can be done to make this difficult: continually make small cosmetic changes to your generated pages to make automatic crawling/pattern recognition more difficult. I don't particularly think this is feasible.
Next solution: use the client's IP address in the published URL (eg, append it to the "real" URL or whatever).
This second solution, however, introduces a problem: the deep-linker could look at the client's IP and generate the link based upon that (we'll assume Charlie has perfect algorithmic knowledge, as usual). At this point, you need to use actual encryption. One way hash won't work and public key makes no sense in this context, so you need a traditional symmetric cipher, with the overlapping key change schedule.
Upon consideration, I realize that this scheme is, in a way, establishing a "session." I can't think of any advantages that this would have over a regular encrypted session cookie, so the whole idea doesn't seem so good with the final analysis. I guess the best way to solve the original problem would be with session cookies, set from your site's front page, encrypted using the described key-change schedule. Using the changing key schedule is better than setting a timestamp in the cookie since it avoids ciphertext attacks.
Damn...can't let this slip by, as it seems this mistake is now being propagated.
Capitolism is not English; capitalism is English.
The economic principle of the materials necessary for production is called capital; the city that is the official seat of government is also called the capital. The white house is the capitol (chief statehouse) of the United States. When used as a proper noun designating the White House, it is capitalized: "The Capitol houses President Bush," but "The White House is the capitol of the US, and Bush is the president of the US." NB that the same priniciple (not principal:) of capitalization (not capitolization:) applies to the word president as well.
Yes, but having the "real" URL won't help since it's only used internally (eg, clients can't access your pages using the real URL, only "encrypted" URLs). Once you've "decrypted" the URL (which is trivially easy, since this is just XOR with a constant string), you can manually XOR URLs for the next hour, at which time the XOR string is regenerated.
So, to "break" this for one hour is as hard as breaking XOR with a constant string (eg, trivial); "breaking" this to work indefinitely is as hard as breaking a OTP (eg, impossible, unless I missed something).
This is why I mentioned this requires some thought, it's non-obvious whether this is completely secure or completely insecure (because it's not anything in between).
NiftyTelnet is basically the standard ssh client for MacOS 8/9. OS X comes with a real ssh, so you don't have to use it there, but on OS 8/9, you're stuck with NiftyTelnet or MacSSH. I don't really like NiftyTelnet all that much, but it does have some advantages over Terminal.app, such as:
Terminal.app does not work with any fonts other than the default one. You would think that any monospace font would work, but it's not the case; you get screen corruption with all fonts except the default. This is a documented problem and Apple is working on it according to our rep. Many times I have screwed up scripts because I wasn't using the default font (I usually give up, go to a Linux box and ssh in to fix it). The default font is very small, especially at high resolutions, and the font selection dialog box does not make it clear which fonts are monospace (laughable idea, but I think you are supposed to "know" which fonts are monospace from the names).
Nifty telnet allows you to assign the "CMD" key to META, where God intended the meta key to belong. With Terminal.app, you can use the "alt/option" key for meta if you muck around in the dialogs, but it still makes Terminal.app completely unusable for an emacs user. (I'm a die-hard vi user for all the admin stuff I do with OS X, but I need my heavily-customized emacs (~90 Kb.emacs) to do any C coding - thus, I don't do any C coding on OS X.)
Terminal.app steals page up/page down for its scroll bar. NiftyTelnet sends them to your programs. Not a big gripe since I can't think of many applications where I use page up/page down.
Anyway, Terminal.app completely sucks if you ever want to do any unix work with an OS X box. There are only four alternatives to Terminal.app:
This thing called "GLTerm." Worse than Terminal.app; not worth your time.
Install rootless X and use xterm or rxvt. Works fairly well, but it's stupid that I have to install X just for a decent terminal emulator.
If you only need to ssh out, use NiftyTelnet in Classic mode. I actually need to work with the OS X box, so this doesn't help unless I combine it with the next possibility:
SSH into the OS X box to do any real work. This is the only way I work with OS X - I ssh in from an xterm on my FreeBSD laptop, using VNC whenever I find yet another annoying thing I can't do from the command line.
This is for the newest version of OS X Server (have to use it, management likes the little GUI user management crap), but regular (client) OS X is exactly the same.
Suppose you use
3DES to encrypt the expiration timestamp,
Great idea, but the implementation can be improved.
There is no communication here - the server encrypts the message, the server decrypts the message. Thus, there is no need for using traditional crypto.
Do this instead: choose a period for when you want links to time out. Say, one hour. Then every hour, the server generates a cryptographically strong random string. All links are XORed with this random string for one hour, at which time the XOR string changes again.
Think about this a bit (actually think about it, it's an interesting exercise), and you'll see it's far stronger than 3DES or any other symmetric cipher, both cryptographically and protocol-wise. It should also be easier to implement. Hell, I think I could code up an apache module to do this PDQ if you pay me. And I'll even take less money than your legal team:)
I agree with your point but would like to point out that I prefer 5400 rpm IDE disks. I've gone through a lot of disks on a lot of machines, and all my IDE disks have failed at some point, but the 7200 rpm disks have always failed much sooner than the 5400 rpm disks. If I actually need the speed on a particular machine, I'll go with SCSI (and if I really need the speed, I'll go with RAID, but it's rare that that's warranted). The SCSI disks also seem to last much much longer than the IDE counterparts (every IDE disk I've had for more than five years has failed, but I still have a bunch of SCSI disks in this Sparcstation from 1994 that haven't given me any problems - those disks were big, heavy and built like tanks).
The longer lifetime on the 5400 RPM disks just makes my life easier. Depends on what you're doing, but if these are regular "business" desktop machines, 5400 RPM disks are plenty fast and might save you some work.
20:01 Tuesday 30 April 2002
19:59 Tuesday 30 April 2002
19:55 Tuesday 30 April 2002
19:33 Tuesday 30 April 2002
19:20 Tuesday 30 April 2002
19:14 Tuesday 30 April 2002
19:09 Tuesday 30 April 2002
18:58 Tuesday 30 April 2002
18:54 Tuesday 30 April 2002
16:17 Tuesday 30 April 2002
16:07 Tuesday 30 April 2002
15:54 Tuesday 30 April 2002
15:51 Tuesday 30 April 2002
15:47 Tuesday 30 April 2002
14:24 Tuesday 30 April 2002
13:52 Tuesday 30 April 2002
13:17 Tuesday 30 April 2002
12:40 Tuesday 30 April 2002
10:47 Tuesday 30 April 2002
10:39 Tuesday 30 April 2002
9:59 Tuesday 30 April 2002
9:51 Tuesday 30 April 2002
9:31 Tuesday 30 April 2002
You have done absolutely nothing but post to Slashdot all day. This is a Tuesday for Christ's sake. Slashdot karma should be the least of your worries. Get a job, go to class, do some homework or read a book - you went to Columbia, you won't find sufficient intellectual stimulation reading slashdot all day. Seriously, turn off the computer. If there's something wrong, you're not going to find any answers on slashdot.
"Trumph" is not a word and generally, the apostrophe is used only for possession or contraction and never for conjugation. Other than that, your English is excellent, and I only mention this because it was very difficult for me (a native speaker) to figure out what those phrases meant. Not a flame; I'm certain your English is much better than my French:)
I'm already tired of explaining to enquiring non-nerds that my nerd-friends are Emacs developers, not
iMac's developers.
No joke. You look through the emacs newsgroups and it seems once every few weeks there's a message from someone looking to buy a peripheral for an iMac. Not a big deal since these people are usually humble and innocent, so they get a few kind and polite responses directing them elsewhere, but still...now that we have eMacs and Emacs we might be seeing a lot more of this.
Example: you want to install a network print driver. Now, your driver needs to do a couple of things: copy itself (it's a dll) into the system directory to be loaded by the windows printing subsystem and create a bunch of registry keys the printing subsystem expects out of each "port monitor". It also needs to inform the printing subsystem to load your dll, either now (NT/2000) or after a reboot (9x). This is where it gets hairy.
The way this is done differs with every version of windows. To ameliorate the problem, MS has a win32 function that you call that does this semi-automatically (I forget what it's called, search MSDN Platform SDK for "install port monitor"). Your print driver won't work unless you call this function.
So, my basic point is that in order to install this software, you need the ability to call arbitrary functions with particular arguments. This basically means the install program must have a place where it runs an arbitrary bit of code written by the developer. You could also do whatever you like in that bit of code, such as uninstalling adaware.
I don't know about MS's new installation procedures, but I'd imagine they're pretty similar to what InstallShield does. The way InstallShield works is that you get this little GUI where you describe your app's files, registry settings, etc. From this, the InstallShield program generates a.ins file which is distributed with a more-or-less generic "setup.exe" program. The setup program also allows you to put in any code that you would like to run (the GUI has you do this in VB, but I believe you could also have it do it in C if you'd like - moot point, since you can do this stuff from VB as well as C). So, the existing installation procedures are something like what you describe except that the developer also gets to run a script of their choosing. In a way, you get the exact same capabilities as with RPM.
Now, you may say that this example is a bit unfair because this is really a device driver and you could say this "systems level" stuff is quite different from regular "application level" software.
Problem with that argument is that in Windows, there is no clear distinction between systems-level and application-level stuff. I'm a unix guy, and it's amazing how much stuff in Win32 is considered "systems level." I'd say almost any non-trivial win32 application would need to have a run of arbitrary code in the installer, whereas most RPMs don't need post-install or pre-install scripts. Underlying problem is that MS got a lot of abstractions wrong.
Yeah, I actually went with the BootX route on these things, even though I found it a bit distasteful leaving a 100 MB MacOS partition which is only used for booting. I got 'em to boot using Open Firmware, but I've had bad experiences struggling with SCSI settings in the firmware on older Suns, so I was kind of glad to bypass Open Firmware.
The machines were actually 5400s, which have 603e PPC chips. I figured that was a first-gen PPC chip, but I never looked into it. I believe this was the first Mac to use PCI instead of NuBus, or whatever they used before PCI. I also noted a couple of PCI problems, like PCI cards randomly not being initialized on boot (but reboot and it usually comes up OK). Still, I'd say these firmware problems are nothing compared to problems I've seen with PC BIOSes: like the 528 MB, 2 GB, 40 GB drive limits, all of which I've run into, or completely broken APM implementations, etc.
Linux on a Mac is harder than that. I got up and running on an old old mac with 32M ram, harder than
what that guy did (boot red hat installer and leave overnight).
I feel your pain. I had to get Linux running on a bunch of old Macs. God, those machines sucked. 16M ram, 180 MHz first-generation PowerPC. Getting X to work was such a PITA - it uses the kernel framebuffer stuff which, at the time, was undocumented. Had to go searching through kernel source to figure out what boot paramaters to pass it. These things were so damned slow - felt like a 386 even though they're supposed to be faster than that. There's like a half second latency for any exec(), even for stuff you've just run - makes every mundane 'ls' seem like a big event.
These machines were constantly swapping - even when you weren't doing anything, the disk was busy. Thus, these things chewed through hard disks right quick (fortunately, Macs don't have b0rked BIOSes like PCs and even the oldest Macs with IDE can accept the newest, biggest hard drives). Compiling anything is an overnight process, and compiling kernels was a week-long process (try it, come back next day, figure out what broke the build, fix it, try again, ad nauseam).
I had to actually code for this thing. Oh, how that sucked. Even using 'vi' was too damned slow. Formatting man pages took like thirty seconds. Of course, I would do all my development on a real machine and port it over, but I still had to work with the damned Macs when my compile broke because they had a different version of some library and so on.
The exec() thing was killer. My code needed to use multiple processes or threads. The multiprocess approach didn't work too well, and using threads didn't help as there's little difference between a thread and a process in Linux (compared to Solaris, for instance). I started playing with using MIT pthreads compiled to do in-process threading, just to get decent performance (lazy, didn't want to write my own in-process scheduler). I eventually just gave up and just let the damned things run slow.
I assume you're talking about this:
Math in the Future according to the Simpsons. (I apologize for linking directly to a large file, the guy didn't have <a name> tags on his page.)
In this context, your AC post is actually quite amusing.
Yes dear, I have written code in PostScript, both hand-coded programs (to generate forms etc) and machine
generated (ie I've written PostScript printer drivers). In the mid 1980s IIRC.
Fair enough; you gain my respect. However, your original post made it seem like this was something new (We'll have people posting documents in PCL5 next, perhaps a subtle troll?).
Like you said, whether posting PostScript is appropriate depends on your audience. This paper was from a guy in the CS department at Cornell, so I'd say it was altogether appropriate. I'd say less than one tenth of the posters here on slashdot read the paper, since it talks about automata theory and does not at all concentrate on spam busting. Those versed in automata theory have probably been through a traditional CS/Math program which means they've certainly seen papers in PostScript.
Slashdot Mirror
Nobody has yet replied to this point (subtle, this is easy to miss unless you've worked with people).
This is because adsl-connect is probably not in your PATH (I'm guessing it's in /sbin or /usr/sbin). You can do a 'man bash', hit the '/' key, type in PATH and keep typing 'n' until you find the entry in the manual page explaining how PATH works.
Short story: type in the following:
Make sure to type in the dash in the 'su' command. The second command should tell you exactly where adsl-connect is, and you can go from there.OS X, like most unices, doesn't honor the set-uid bit for scripts.
I would just write a trivial C program and make that set-uid:
On OS X, install dev tools, compile as "cc file.c -o my-script" and then "chmod 4755 my-script". You can then run it from a normal user shell and the script is run as root (make sure the file is owned by root).
NB: I'm not replying directly to you, but rather to the original poster who wanted to know how to do this.
Please, actually work with these people before trying to tell me how it would be so easy to convert them to unix. It's completely different in a corporate environment than the home environment (and I don't see OS X being targetted at corporate environments, so we're talking about mom and pop and their home computer here). In a corporate environment, they have you to get the machine working and install new software, etc. You try to put unix in a mom-and-pop home environment, and you'll be inundated with phone calls. You'll fix something for them (which will require root privs) and then you'll get another phone call 20 minutes later.
Try installing a mozilla build without using a command line, logged in as a regular user. Sure, you just install it to your home directory, but how many people are going to figure out that they need to change the default value in the dialog box? After you've installed it to your home directory, how do you start it up? Well, maybe it installed an icon on your KDE/GNOME desktop, maybe not. Let's assume it has. Now, what if you're in Konqueror and you want to use the "Open using Mozilla" menu option. Do you think that will work? Nope. Mozilla is not in your PATH (and that is what the latest version of Konqueror uses - it just does an execvp). Do you walk your grandmother through editing her .bashrc using emacs?
These people don't know the difference between a slash and a backslash - you'll have difficulties telling them over the telephone exactly which characters to type in, one at a time. When I say "et-see are see dot dee init dot dee" you think "/etc/rc.d/init.d" but mom-and-pop thinks "WTF?" You'll then give up, go to their physical location, enable ssh, and fix everything remotely from then on.
I have a lot of patience - I regularly deal with intelligent non-computer people (I have a real job, you see) and I've very good at explaining technical matters to non-technical people, but dealing with this audience is a completely different matter - you will become frustrated sooner or later. It's not really a matter of patience, but a matter of communication. When filesystem permissions and the simple relationship between users and groups doesn't make sense to someone, you simply don't have a common vocabulary to communicate expediently. They will log in as root no matter what you tell them. Ask yourself how many people are running Windows 2000/XP on their laptops and how many of those people bothered to create a non-Administrator account.
Dude, you're using the wrong shell:
NB: this is zsh figuring out my typo, not 'rm' being annoying.
I'll only tell you the anectdote salient to this article. He would, of course, only log in as root as the KDE rpm front-end wouldn't work when you're logged in as a regular user and he didn't want to figure out how to use the the command-line rpm (I don't know if currently KDE does a sudo/su-type thing using the GUI, but it didn't back then - if you ran kfm as non-root, you couldn't use the RPM front-end).
At one point he could no longer log in. Problem? / was full. He was downloading all his stuff into /root (a one gig partition) and /home (20 gig partition) was completely empty. You could log in from console, but not from XDM since XDM creates files in /tmp upon login. He had no idea how to get from XDM to another virtual console, so he was effectively locked out of his machine.
My point? Give up. Don't worry about it. They will not learn why logging in as root is bad until they get burned. Especially since you're just a forum moderator - if you were getting paid to do this and your job depended on these machines staying up, you would have every responsibility to ensure people were properly following your policies; but, as a mere guru to these people, allow them to learn in the most effective fashion: trial by error.
You want to change all your .emacs, .exrc, .whatever to be world-readable so everyone can see just how clever you are:
Well, not so clever after all. '.*' expands to include '..' and '.' and the -R flag combines with this in a Very Bad Way. I got burned by this once (different circumstances, however, I su'ed into root to change some stuff in /tmp). This also depends on what shell you use: with bash, you're screwed, with zsh, you're OK.
They had a HUGE explosion of these things. This movie showed them in hoards. It also had this one scene with this hippie - the guy had a VW van and his hobby was to go around smashing these things. He would swerve the van from one side of the street to the other, running over the toads which would make a very satisfying pop. This hippie is the only thing I remember from high school biology.
So, my point is that these toads were introduced for an ecological reason (pest control), but apparently these guys didn't understand ecology all that well. Of course, this Hawaii thing is different since the frogs weren't introduced intentionally, but it seems toads/frogs have a talent for growing explosively.
Now, after months of filing proposals, he has won a 4.5 million baht ($104,200) grant from Thailand's National Research Council. The grant will help him finance a patent with the World Intellectual Property Organization.
So, the guy could only get a patent after he received help from the government.
Now, let's read some more of the article:
With 2 million baht in savings he set up a small factory in his provincial hometown of Chonburi. The factory can produce only 1,000-2,000 balls daily.
So, the guy used 2M baht in capital for starting his company, but he needs over twice that amount to get a patent.
Wasn't WIPO supposed to help people like this?
Duly noted. I'm big on language but not history/politics, so I didn't know this.
attributed to Gen John W Vessey Jr, US Army, Chairman, Joint Chiefs of Staff
Yes, upon further thought, I realized that this would be necessary. Another couple of problems that I came up with while thinking about it:
Suppose the linking site really wants to deep-link and the guy writing the linking site is technically capable. Now, instead of having a static HTML page or whatever, he could have a webcrawler that fetches the page every hour and publishes that URL. The webcrawler would have to go to your site's front page and walk the link tree down from there until it finds the correct page.
Couple of things can be done to make this difficult: continually make small cosmetic changes to your generated pages to make automatic crawling/pattern recognition more difficult. I don't particularly think this is feasible.
Next solution: use the client's IP address in the published URL (eg, append it to the "real" URL or whatever).
This second solution, however, introduces a problem: the deep-linker could look at the client's IP and generate the link based upon that (we'll assume Charlie has perfect algorithmic knowledge, as usual). At this point, you need to use actual encryption. One way hash won't work and public key makes no sense in this context, so you need a traditional symmetric cipher, with the overlapping key change schedule.
Upon consideration, I realize that this scheme is, in a way, establishing a "session." I can't think of any advantages that this would have over a regular encrypted session cookie, so the whole idea doesn't seem so good with the final analysis. I guess the best way to solve the original problem would be with session cookies, set from your site's front page, encrypted using the described key-change schedule. Using the changing key schedule is better than setting a timestamp in the cookie since it avoids ciphertext attacks.
Still, this is a very interesting probem.
Capitolism has nothing to do with....
Damn...can't let this slip by, as it seems this mistake is now being propagated.
Capitolism is not English; capitalism is English.
The economic principle of the materials necessary for production is called capital; the city that is the official seat of government is also called the capital. The white house is the capitol (chief statehouse) of the United States. When used as a proper noun designating the White House, it is capitalized: "The Capitol houses President Bush," but "The White House is the capitol of the US, and Bush is the president of the US." NB that the same priniciple (not principal :) of capitalization (not capitolization :) applies to the word president as well.
Redundant: Here, and here. I'm guessing this is going to be the Mac equivalent of "BSD is dying." Funny how this was modded up.
So, to "break" this for one hour is as hard as breaking XOR with a constant string (eg, trivial); "breaking" this to work indefinitely is as hard as breaking a OTP (eg, impossible, unless I missed something). This is why I mentioned this requires some thought, it's non-obvious whether this is completely secure or completely insecure (because it's not anything in between).
-
Terminal.app does not work with any fonts other than the default one. You would think that any monospace font would work, but it's not the case; you get screen corruption with all fonts except the default. This is a documented problem and Apple is working on it according to our rep. Many times I have screwed up scripts because I wasn't using the default font (I usually give up, go to a Linux box and ssh in to fix it). The default font is very small, especially at high resolutions, and the font selection dialog box does not make it clear which fonts are monospace (laughable idea, but I think you are supposed to "know" which fonts are monospace from the names).
-
Nifty telnet allows you to assign the "CMD" key to META, where God intended the meta key to belong. With Terminal.app, you can use the "alt/option" key for meta if you muck around in the dialogs, but it still makes Terminal.app completely unusable for an emacs user. (I'm a die-hard vi user for all the admin stuff I do with OS X, but I need my heavily-customized emacs (~90 Kb
.emacs) to do any C coding - thus, I don't do any C coding on OS X.)
-
Terminal.app steals page up/page down for its scroll bar. NiftyTelnet sends them to your programs. Not a big gripe since I can't think of many applications where I use page up/page down.
Anyway, Terminal.app completely sucks if you ever want to do any unix work with an OS X box. There are only four alternatives to Terminal.app:- This thing called "GLTerm." Worse than Terminal.app; not worth your time.
- Install rootless X and use xterm or rxvt. Works fairly well, but it's stupid that I have to install X just for a decent terminal emulator.
- If you only need to ssh out, use NiftyTelnet in Classic mode. I actually need to work with the OS X box, so this doesn't help unless I combine it with the next possibility:
- SSH into the OS X box to do any real work. This is the only way I work with OS X - I ssh in from an xterm on my FreeBSD laptop, using VNC whenever I find yet another annoying thing I can't do from the command line.
This is for the newest version of OS X Server (have to use it, management likes the little GUI user management crap), but regular (client) OS X is exactly the same.Great idea, but the implementation can be improved.
There is no communication here - the server encrypts the message, the server decrypts the message. Thus, there is no need for using traditional crypto.
Do this instead: choose a period for when you want links to time out. Say, one hour. Then every hour, the server generates a cryptographically strong random string. All links are XORed with this random string for one hour, at which time the XOR string changes again.
Think about this a bit (actually think about it, it's an interesting exercise), and you'll see it's far stronger than 3DES or any other symmetric cipher, both cryptographically and protocol-wise. It should also be easier to implement. Hell, I think I could code up an apache module to do this PDQ if you pay me. And I'll even take less money than your legal team :)
I agree with your point but would like to point out that I prefer 5400 rpm IDE disks. I've gone through a lot of disks on a lot of machines, and all my IDE disks have failed at some point, but the 7200 rpm disks have always failed much sooner than the 5400 rpm disks. If I actually need the speed on a particular machine, I'll go with SCSI (and if I really need the speed, I'll go with RAID, but it's rare that that's warranted). The SCSI disks also seem to last much much longer than the IDE counterparts (every IDE disk I've had for more than five years has failed, but I still have a bunch of SCSI disks in this Sparcstation from 1994 that haven't given me any problems - those disks were big, heavy and built like tanks).
The longer lifetime on the 5400 RPM disks just makes my life easier. Depends on what you're doing, but if these are regular "business" desktop machines, 5400 RPM disks are plenty fast and might save you some work.
20:01 Tuesday 30 April 2002
19:59 Tuesday 30 April 2002
19:55 Tuesday 30 April 2002
19:33 Tuesday 30 April 2002
19:20 Tuesday 30 April 2002
19:14 Tuesday 30 April 2002
19:09 Tuesday 30 April 2002
18:58 Tuesday 30 April 2002
18:54 Tuesday 30 April 2002
16:17 Tuesday 30 April 2002
16:07 Tuesday 30 April 2002
15:54 Tuesday 30 April 2002
15:51 Tuesday 30 April 2002
15:47 Tuesday 30 April 2002
14:24 Tuesday 30 April 2002
13:52 Tuesday 30 April 2002
13:17 Tuesday 30 April 2002
12:40 Tuesday 30 April 2002
10:47 Tuesday 30 April 2002
10:39 Tuesday 30 April 2002
9:59 Tuesday 30 April 2002
9:51 Tuesday 30 April 2002
9:31 Tuesday 30 April 2002
You have done absolutely nothing but post to Slashdot all day. This is a Tuesday for Christ's sake. Slashdot karma should be the least of your worries. Get a job, go to class, do some homework or read a book - you went to Columbia, you won't find sufficient intellectual stimulation reading slashdot all day. Seriously, turn off the computer. If there's something wrong, you're not going to find any answers on slashdot.
Market share trumph's innovation.
Correct way:
Market share trumps evolution.
Market share trumps innovation.
"Trumph" is not a word and generally, the apostrophe is used only for possession or contraction and never for conjugation. Other than that, your English is excellent, and I only mention this because it was very difficult for me (a native speaker) to figure out what those phrases meant. Not a flame; I'm certain your English is much better than my French :)
No joke. You look through the emacs newsgroups and it seems once every few weeks there's a message from someone looking to buy a peripheral for an iMac. Not a big deal since these people are usually humble and innocent, so they get a few kind and polite responses directing them elsewhere, but still...now that we have eMacs and Emacs we might be seeing a lot more of this.
Unfortunately, this won't work in Windows.
Example: you want to install a network print driver. Now, your driver needs to do a couple of things: copy itself (it's a dll) into the system directory to be loaded by the windows printing subsystem and create a bunch of registry keys the printing subsystem expects out of each "port monitor". It also needs to inform the printing subsystem to load your dll, either now (NT/2000) or after a reboot (9x). This is where it gets hairy.
The way this is done differs with every version of windows. To ameliorate the problem, MS has a win32 function that you call that does this semi-automatically (I forget what it's called, search MSDN Platform SDK for "install port monitor"). Your print driver won't work unless you call this function.
So, my basic point is that in order to install this software, you need the ability to call arbitrary functions with particular arguments. This basically means the install program must have a place where it runs an arbitrary bit of code written by the developer. You could also do whatever you like in that bit of code, such as uninstalling adaware.
I don't know about MS's new installation procedures, but I'd imagine they're pretty similar to what InstallShield does. The way InstallShield works is that you get this little GUI where you describe your app's files, registry settings, etc. From this, the InstallShield program generates a .ins file which is distributed with a more-or-less generic "setup.exe" program. The setup program also allows you to put in any code that you would like to run (the GUI has you do this in VB, but I believe you could also have it do it in C if you'd like - moot point, since you can do this stuff from VB as well as C). So, the existing installation procedures are something like what you describe except that the developer also gets to run a script of their choosing. In a way, you get the exact same capabilities as with RPM.
Now, you may say that this example is a bit unfair because this is really a device driver and you could say this "systems level" stuff is quite different from regular "application level" software.
Problem with that argument is that in Windows, there is no clear distinction between systems-level and application-level stuff. I'm a unix guy, and it's amazing how much stuff in Win32 is considered "systems level." I'd say almost any non-trivial win32 application would need to have a run of arbitrary code in the installer, whereas most RPMs don't need post-install or pre-install scripts. Underlying problem is that MS got a lot of abstractions wrong.
The machines were actually 5400s, which have 603e PPC chips. I figured that was a first-gen PPC chip, but I never looked into it. I believe this was the first Mac to use PCI instead of NuBus, or whatever they used before PCI. I also noted a couple of PCI problems, like PCI cards randomly not being initialized on boot (but reboot and it usually comes up OK). Still, I'd say these firmware problems are nothing compared to problems I've seen with PC BIOSes: like the 528 MB, 2 GB, 40 GB drive limits, all of which I've run into, or completely broken APM implementations, etc.
I feel your pain. I had to get Linux running on a bunch of old Macs. God, those machines sucked. 16M ram, 180 MHz first-generation PowerPC. Getting X to work was such a PITA - it uses the kernel framebuffer stuff which, at the time, was undocumented. Had to go searching through kernel source to figure out what boot paramaters to pass it. These things were so damned slow - felt like a 386 even though they're supposed to be faster than that. There's like a half second latency for any exec(), even for stuff you've just run - makes every mundane 'ls' seem like a big event.
These machines were constantly swapping - even when you weren't doing anything, the disk was busy. Thus, these things chewed through hard disks right quick (fortunately, Macs don't have b0rked BIOSes like PCs and even the oldest Macs with IDE can accept the newest, biggest hard drives). Compiling anything is an overnight process, and compiling kernels was a week-long process (try it, come back next day, figure out what broke the build, fix it, try again, ad nauseam).
I had to actually code for this thing. Oh, how that sucked. Even using 'vi' was too damned slow. Formatting man pages took like thirty seconds. Of course, I would do all my development on a real machine and port it over, but I still had to work with the damned Macs when my compile broke because they had a different version of some library and so on.
The exec() thing was killer. My code needed to use multiple processes or threads. The multiprocess approach didn't work too well, and using threads didn't help as there's little difference between a thread and a process in Linux (compared to Solaris, for instance). I started playing with using MIT pthreads compiled to do in-process threading, just to get decent performance (lazy, didn't want to write my own in-process scheduler). I eventually just gave up and just let the damned things run slow.
Never again.
Partial Credit!
I assume you're talking about this: Math in the Future according to the Simpsons. (I apologize for linking directly to a large file, the guy didn't have <a name> tags on his page.)
In this context, your AC post is actually quite amusing.
Fair enough; you gain my respect. However, your original post made it seem like this was something new (We'll have people posting documents in PCL5 next, perhaps a subtle troll?).
Like you said, whether posting PostScript is appropriate depends on your audience. This paper was from a guy in the CS department at Cornell, so I'd say it was altogether appropriate. I'd say less than one tenth of the posters here on slashdot read the paper, since it talks about automata theory and does not at all concentrate on spam busting. Those versed in automata theory have probably been through a traditional CS/Math program which means they've certainly seen papers in PostScript.