Absolutely. Sounds like a much more elegant way of doing things.
Quite a bit different, however. Certainly takes a different frame of mind and sounds like a different workflow as well.
I have a largish tree that's in dire need of some revision control. If things go as planned, it will be developed in multiple branches and will have automated remote checkouts (maybe even automated unit testing). I was just going to go with CVS, but I'm interested enough that I'll experiment with some of these new-fangled revision control systems. It looks like FreeBSD et al. will have a more difficult time changing systems, but I have a perfect opportunity for experimentation.
2. Support for (user-supplied) keywords. The general consensus on the Arch list is that it's a bad idea for any revision control system to support this "feature" at all, and that there are better ways to do anything one could want them for.
1. Why is this a bad idea?
2. What are these better methods for doing the same thing?
For those who don't know what we're talking about, this is the $FreeBSD: $ tag you see in source files. XFree86 also uses this as $XFree86: $. It basically replaces the $Id: $ or $Header: $ keyword.
Projects like FreeBSD need this because they maintain separate trees for a number of projects maintained by other people. They do this because:
It facilitates distributing this code to end-users. I can cvsup my FreeBSD tree and pull in the correct version of OpenSSL. I don't have to cvsup my FreeBSD tree, then go download the right version of OpenSSL and apply it to the tree.
Sometimes certain projects need portability fixes to work with FreeBSD. These fixes are applied to the FreeBSD tree before they're distributed in the project's branch. Sometimes security fixes also come in here.
Sometimes FreeBSD-specific features are added. For instance, some network code could use sendfile(2) which is BSD-specific but has parallels in Linux and Windows. This code might never make it into the project's main branch but has to be patched in whenever the project releases a new version.
It makes perfect sense that one would want to see what version a particular file is in FreeBSD's tree and in the project's tree.
Example (older tree):
RCSID("$OpenBSD: ssh-agent.c,v 1.97 2002/06/24 14:55:38 markus Exp $"); RCSID("$FreeBSD: src/crypto/openssh/ssh-agent.c,v 1.2.2.7.4.1 2002/07/16 12:33:09 des Exp $");
OpenSSH has had a number of vulnerabilities over the past year. The situation is certain to improve now with privilege separation, but it's nonetheless the case that I spent time upgrading OpenSSH on a number of machines over the past year or two. The idea here is that perhaps some people haven't noticed that OpenSSH has had a number of vulnerabilities because they have to update their machines anyway, but I have a run of machines where the only thing I have to worry about is OpenSSH and remote kernel vulnerabilities (no local users, all custom network services) and I've noticed that OpenSSH has had a number of vulnerabilities and potential vulnerabilities.
Combine this with the fact that many newbies to Linux do not need SSH. One of the things I enjoy doing is working with *nix newbies (believe it or not) and many of them couldn't care less about accessing their machine remotely. Now these newbies are the same people who don't know how to turn off services and aren't subscribed to any vulnerability mailing lists, so they end up running something vulnerable and not knowing about it.
So, I don't believe you should qualify your statement in any way. All operating systems should default to listening on absolutely no ports after install. Turning on ssh is just a minor inconvenience for us, but having vulnerable machines on a network is a major PITA for everybody. You could make a case that ssh should be turned on if you're doing a network/headless install, but for a regular boot-off-CD/partition/format/install sequence, the only way the machine should respond is with RST, port-unreachable and echo-reply.
The only vendor I know of that's doing this correctly is Apple. The only network services they have on by default are portmap and netinfo and if you read their boot scripts, they plan to turn these off by default after they've dealt with some issues in 10.4. There may be some lesser-known Linux distros that do this as well, but you are correct in that the major distros turn on uneccessary services by default.
Give up copyrights to the community and let the community to help you writing the text.
I hope you're joking.
Have you tried reading TAoCP? This is not some computer book but is an in-depth study of all the mathematics that Computer Science comprises. Some of the exercies would serve as topics for a PhD thesis (and are marked as such).
Suffice it to say that writing these books is not an easy task and I'm not sure if the series will ever get finished. I'm still on the first volume, so I don't know if I'll ever finish the series. Even though wikipedia shows us that a community effort can produce some good writing, I doubt it could ever produce something as in-depth as TAoCP.
And besides this, I think Addison-Wesley would have something to say about putting TAoCP in public domain.
I know of only one application that uses deflate but does not use zlib: putty (Windows ssh client). Excellent code, uses own zlib implementation partly to avoid monoculture, partly for other (very good) reasons.
Another culprit is OpenSSL. I'd REALLY like to see a nonrestrictive-licensed (BSD or public domain, not GPL) API-compatible OpenSSL alternative. In fact, I'm considering doing it myself, but I'm not fooling myself about how much work this is.
Other (smaller) examples: MD5. All code I've seen uses the same public domain MD5 implementation. The code is short enough that security shouldn't be an issue, but it's still a bit strange that everyone uses the same code when MD5 is a publicized Internet standard.
One really dangerous example is ASN.1. This is so horribly complex (commitee-designed) that nobody would want to implement an ASN.1 encoder/decoder when a public domain implementation exists, so everybody uses the same code. This is the code that caused those SNMP vulnerabilities a while ago: good example of code monoculture since it affected *nix, Windows and even embedded stuff like Cisco IOS.
One would normally not see this as the canonical form is:
find . -name filename -print
This is faster as it does not need to send information between two processes using an IPC mechanism (the pipe) and it avoids unecessary computation ("grep filename" may be slower (depending on the grep implementation) than simple filename comparison a la fgrep).
If you're actually going to use a regular expression to search for a file, the more common method is:
find . -type f -print | grep 'regex'
This avoids printing directories. Add '[^/]*$' to the end of the regex to avoid matches in directory names. Many versions of "find" (including Mac OS X "find") support a "-regex" option, but this is nonstandard.
If your search allows it, even better is:
sudo/usr/libexec/locate.updatedb # run once a day or so locate filename
I'm not suggesting that you didn't know these things, but you can be certain that (due to the nature of the article) some *nix newbies will read your post and they may start doing those commands on a regular basis, not knowing of better alternatives, so one should be careful when posting these things to such a forum.
A lot of my work is Windows integration. This involves a bit of reverse engineering (days looking at hex dumps) and a lot of online research as Microsoft documents many things very poorly.
For instance, one of my recent projects was writing a replacement GINA for Windows. This is the component that determines authorization, eg, the login window and associated logic. There were various that reasons existing products and projects were unsuitable. Microsoft's documentation is absolutely, incontrovertibly horrible (so incomplete that I get the distinct feeling it's intentionally meant to stop integration efforts). However, I managed to get through it by some reverse engineering (testing how various parameters affect a function) and some online research (third party websites, wine source when GPL is OK for the project).
What if Microsoft decides that I couldn't have done this without access to their source? There are only a few companies that write real GINAs without passing through actual login to MSGINA and I know some of them have access to source, so it may have been very helpful.
Obviously, I'm staying as far away from the leaked code as possible. In fact, I'm hesitant to even post to Slashdot as that might remotely associate me with some people that have the files or I might accidentally glance at a file listing or code snippet from some careless individual.
I'm not naive: I know that if I get taken to court, I'll be the one that has to prove that I never looked at the source. How the hell am I supposed to do that?
Even worse, a lot of the documentation I use comes from people who've reverse engineered it out of Windows. When I read something online, how am I supposed to know if it came from someone who truly reverse engineered it or from someone who had illegitimate source access? IAANAL (obviously) so this might even be OK legally, but I know that if Microsoft goes after me, I'll be destroyed due to their resources so I put little faith in the law (and Microsoft really hates people like me, I get people off of AD onto standard LDAP schemas).
Some of my other projects include remote filesystems via IFS and some various driver-level stuff. This really, really scares me. I spent days looking at hex dumps to get some things working. For a lot of projects the only way to test anything is a reboot, so I've put a lot of time into these projects and this leak gives Microsoft an opportunity to easily destroy all my work.
I'm seriously thinking of talking to a lawyer RIGHT NOW as I'd like to know exactly how I can protect my livelihood from now on and what steps I can take to gather evidence that I've never looked at Windows source.
how much do you think its going to be in man-hours to have a programmer fix something in Wine or OpenOffice if my insanely complex budgetting Excel macro fails?
How much do you think it's going to be in man-hours to have a programmer fix a bug in MS-SQL Server if my insanely complex budgeting query crashes the server?
Bad question. The answer is irrelevant since it won't happen: you have to wait for Microsoft to fix that bug, no matter how much the bug is costing you.
Open source software provides additional flexibility: if there's something wrong, you are not at the mercy of the vendor and can fix it yourself if it's important enough. Proprietary software does not provide this option.
How many people in the world even have the skill to do this within in a few days?
I routinely fix bugs in open source projects: I've submitted small bugfixes and feature patches to Patrick Powel of LPRng, the samba team, the ssh team and numerous small projects. Some of these smaller open source projects were even Windows system-level software written using all of Microsoft's worst practices like Hungarian, pointless typedefing and reserved fields for binary compatibility. I didn't throw myself into the Hell of Windows coding practices because it's fun, but because a particular project had bugs that were affecting deployment at work.
I'd like to think otherwise, but I'm not all that unique: I've met and worked with others with the right skills and background knowlege. The difference is that I'm motivated enough to spend a few hours finding a bug in someone else's code but many people wouldn't even consider it. Perhaps they once tried fixing something in Mozilla or KDE and were discouraged by the immense volume of code: the right place to start is some smaller (less glorious) project, or perhaps something very segmented like the Linux kernel (which I've found to be very friendly to modification).
I think you'll find more and more people able and willing to make source modifications as you gravitate toward open source: like I said, Windows programming (Platform SDK, MFC) is hellish, and it discourages any kind of programming.
Great development tools - javascript console, venkman debugger, live-headers plugin
Don't forget the visual DOM inpector. Inspired me to clean up some nested table madness over the weekend on sites that would have otherwise remained unmanageable indefinitely.
Also, why isn't live-header part of the default install (at least the "view page info" tab, not necessarily the menu item)? It's ridiculous that I have to run a sniffer to do simple web development when some cache control issue comes up (and lots of good a sniffer will do you when you have to keep the site behind ssl - sure, openssl s_client/s_server can help, but toggling between the two gets old fast).
I really don't understand how browser writers could have missed such a simple feature for so long - analagous to a MUA that doesn't have a "view headers" option. Don't get me wrong, I don't mind installing an extension, but this feature is long overdue.
For extra fun, try viewing the headers Slashdot sends (X-Bender, X-Fry).
Right-click and go to "customise". Then drag the components to the top toolbar and turn off the one below. Not as easy as drag-and-drop, but perhaps a little more flexible.
More flexible and better from a usability standpoint.
I'm sure we've all received a call from some hopeless soul whose "screen was half gray" because they accidentally dragged the taskbar halfway up the screen. Thus, Windows XP default theme turns off taskbar dragging by default.
Similarly, I've seen MSIE setups where the user has accidentally dragged the address bar above the menu bar or put the menu bar at the extreme right so only "File >>" is showing. They then ask who deleted their bookmarks. Thus, IE 6 has a "Lock the Toolbars" option (unfortunately off by default, but I'm willing to be hard cash it will be on (or toolbars will otherwise be non-draggable) by default in Microsoft's next major browser/OS revision).
Don't even get me started on Microsoft Word and mortified secretaries who can't save because the floppy icon disappeared.
Simple usability lesson is "avoid accidental customization." I find it very unfortunate that GTK and KDE were so quick to adopt Microsoft's perpetually draggable menubars/toolbars. A simple right-click/control-click (or even a menu item to call up a toolbar editor) is more than sufficient and intuitive enough for those who actually want to customize their toolbars.
For most ELF binaries the interpreter is/lib/ld-linux.so.2, and it takes as an argument the binary to run.
Now wouldn't it be nice if malicious code could only be run by those who know how to bypass fascist security restrictions?:)
I'd say noexec buys you something if you can only run a new program after going through a specific process. Namely, you know you're running a new program. I can deal with my users' maliciousness, but my users' foolishness keeps me up at night.
The propagation technique used by the latest so-called "virii" is primarily social engineering. Linux is not inheriently any safer than Windows in this regard.
First, the plural of virus always has been "viruses".
Secondly, if I get an ELF executable in an email, I have to save it to disk, open a terminal, chmod +x it and then type in its name. Double-clicking on a saved executable in a file manager will probably do something like open it with a text editor until you've made it executable.
It might be a little easier if you send an RPM file in email, but then the user opens the file and is asked "Are you sure you want to install package 'such-and-such'?" by the friendly rpm gui manager. Even then, unless the user provides an administrative password (assuming the machine is running some kind of backend gui authenticator like ksudo for KDE or the Security Services API in Mac OS X), there is no way any kind of software can install itself systemwide so it starts on boot, but only to start on login (granted, this makes little difference on a single-user machine).
With these things in mind, you can very easily lock down a system so even this rpm-on-login exploit is impossible if you mount home directories (and/tmp) no-exec. This flag has been standard in Unix variants for a long time and is often used for stuff like NFS-mounted mail spools. It even works in Mac OS X and I've successfully used it for this purpose on specialized kiosk-type applications. This prevents certain users from writing their own programs and scripts, but hopefully one would feel comfortable granting an exception for these more advanced users and giving them some space for programming.
If you read through parts of the agreement (or rather scan through it visually), you'll see that it's not "real" legaleze, but rather sounds like some layperson trying to write legaleze. For instance, "Spamming, as well as repetitive...": "spamming" is a term a lawyer would avoid using as Hormel holds a trademark on "Spam" and asks that it not be used in this context.
I have a method for identifying legaleze, or for that matter, anything written by a lawyer: count the number of times the document uses "in the event that" and compare to the number of times it uses "if". "In the event that" is pure, useless verbiage which can in all circumstances be replaced with "if". It's simply poor writing and is not more "clear" or "exact" than "if", but I guess it's ingrained in lawyer culture, so they continue to use it.
This document uses "in the event that" ten times, but uses "if" over eighty times. Looks like wannabe legaleze to me.
Indeed, if you look at the bottom of the document, you'll find this:
The author of this publication is CPRR.org, a pseudonym. The author, an individual scholar who is not a Counsellor at Law, asserts moral rights.
I guess my point is that this isn't as funny as you would think: if it were an actual lawyer writing this, it would show just how bad things have become around here, but it's not some lawyer, just some random loony.
Another possibility is that this man has just pulled off the most masterful troll in the history of the Internet by fooling thousands of Slashdot readers into rightful indignation. However, the document seems serious about some of the provisions about copying images, so this might not be the case. On the other hand, these more plausible sections may have been added specifically to ward off trollbusters.
In any case, take it with a grain of salt. You might end up looking foolish if you say that this signals the end of American civilization.
You need to take some English courses. You're obviously American - I've worked with ESL students and you make purely American mistakes.
what colleges im going to apply to
I'm not going to get into stylistic subtleties here ("what" instead of "which", preposition "to" separated from its object, using "but" twice in the same sentence with differing puncutation). Instead, I'd like to remind you that the first person singular pronoun is always capitalized in English and that contractions contain apostrophes. I've attempted to read your blog, and you are no e. e. cummings, sir. The poet I mention had very specific justifications for his capitalization, laziness and ignorance not being among these reasons.
I was hoping to find a college with a major, along the lines of Network Engineering, but I have yet to find one.
The comma is commonly used to separate clauses which supply extraneous information. Let's see how well your sentence stands without it:
I was hoping to find a college with a major, but I have yet to find one.
Indeed.
Slashdot is not an instant messaging program. Your words were read by thousands of people. You should at least attempt to demonstrate a mastery of the language you've been using since shortly after your birth. After all, if you present enough of a communication barrier to your superiors, they won't have any qualms looking to the Far East for their engineering.
I think the naysayers are those people who do not understand passion. In this case, it's a passion for understanding and controlling every minute detail of a machine, but anyone who is passionate about something - be it music, writing, mountain climbing or even font design or organic chemistry - can understand the motivation. I'm not really into performance cars, but I think I can understand the drive behind the hotrodders who try to tweak every last bit of performance out of their machines.
Sadly, I find few people who demonstrate passion. It seems like most people would rather have me bug-fixing drivers for their new-fangled 3-d video card than writing a window manager for my own use, just like most people would rather have their brake pads changed by the hotrodders instead of leaving them in peace.
I've found some solace in open source communities as they seem to attract a higher-than-usual percent of people who understand passion, both programmers and users.
Finally, spy-ware is only a problem if it can transmit the information it gathers out of your system to its masters.
Not true at all. In fact, I couldn't care less about spyware transmitting information. When I start to care is when I get a call because someone's machine is malfunctioning.
I've seen numerous spyware hijack IE, replace the startup page, install IE extensions to randomly popup advertisements, change how DNS resolution works, etc. I've seen machines where it takes minutes to start up a browser.
I highly recommend Kerio firewall, by the way; it's free as in beer and quite full-featured.
Kerio is trivial to bypass if you bypass the winsock API and program directly to NDIS. I've done this as a demonstration only, but seeing how spyware is so pernicious, I bet you'll soon see spyware doing the same things.
Application-level firewalls are useless if the user has full access to the machine. If the user has the ability to bypass the firewall, a program can do so just as easily and there is no way in Windows to differentiate between messages coming from keyboard/mouse and messages coming from other applications. Similarly, these are useless if the user has the ability to choose whether a program is put in the firewall's "allowed applications" list, as a malicious program can simply fake the user input and put itself there; on the other hand, taking away this ability from the user is not something I'd like to do, as my users should be free to use Mozilla, Opera or any other browser they choose without going through me.
I think we're talking about different things: I'm not concerned about keeping spyware off of my personal workstations, as these machines never get spyware in the first place due to me being careful about what I run. What I care about is keeping employee machines spyware-free while at the same time allowing users to install their own applications without going through me.
Actually, the situation is exactly the same as with viruses: I don't worry about viruses on my personal machines, but I know my users aren't sophisticated enough to differentiate between an attachment called "file.doc" and "file.doc [fifty spaces].exe", so I install antivirus software on their machines. Similarly, I know they're going to download and execute spyware, so I'd like some tool that runs in the background recognizing spyware and preventing it from running. The paid version of adaware does this, and I consider it a virus scanner that stops viruses written by questionably-legitimate companies instead of individuals.
So there is a place for anti-spyware tools: if you're a sophisticated user on your own machine, you can do without antispyware software, but if you're in a situation where antivirus software is warranted, antispyware software is also a good idea. I just wish McAfee would stop pandering to these spyware "companies" so we wouldn't have to get two site licenses for similar software.
People here are recommending all sorts of books and websites specifically catered to this project. When I did it, I knew of no such resources.
Anyway, I'd recommend doing a google search for 386intel.txt. This is Intel's documentation for the 386 chip, including systems programming stuff. This is the file Linus used. The modern version of this documentation is available here for the Pentium III, split up in three. You'll need all three, but the third in the series is most relevant.
After you get booting, you'll need some documentation for various devices when writing drivers. I used "The Indespensible PC Hardware Book" by Messner and it was pretty good. I guess there are also good websites available and you can always look at how Linux or *BSD does it.
Anyway, you might be able to skip the Intel documentation if you use someone else's bootloader, but I don't recommend this. One of the points of this project should be to understand the machine inside and out from boot, so write your own bootloader and object code loader. Once it can run your C code, you'll get a feeling of satisfaction, which should be another of this project's goals.
I used an older version of VMWare for testing, but I highly recommend bochs nowadays. Bochs seems designed exactly for this stuff, so you can run a debugger right away and you don't need to go through the older debugging route which was to write a serial port driver as soon as possible and get a remote debugger working over that (easiest way to do remote debugging in VMWare and real hardware).
I'd recommend nasm for the assembler bits. It can do 16-bit code for the bootloader and it can spit out unadorned object code so you don't have to bother with parsing ELF and extracting what you need (although you'll need to do this eventually when you get to C, but you can at least delay that until after you start booting).
One last thing - ignore the naysayers. It seems lots of people thought it important to post that you shouldn't be doing this but should instead be contributing some drivers to another project or something like that. Whenever someone in the open source community says this, they're almost always non-developers. Most of us write code on our own time because we find it satisfying and this is one of the most satisfying projects you can undertake. This project is also a kind of "coming-of-age" experience (for lack of a better word), like writing your own compiler or creating a GUI API or window manager. Users won't understand. That's OK. We understand.
Try some Turkish/Greek/Arabic coffee. It's the only stuff I drink and it's what "coffee" means in large parts of the world (Arabic coffee also adds a type of spice, but's it's really the same thing). I'll call it Turkish coffee from here out, with profuse apologies to my Helenic friends.
For the uninitiated: this is pure, unfiltered coffee. A small flask-shaped pot (called an "ibrik") is filled with one heaping teaspoon of coffee for each serving and one half teaspoon of sugar to taste. The coffee must be ground to a fine powder or the flavor won't be extracted, and for maximum flavor, you must buy beans and grind them yourself (don't let the powder sit for too long). If you're really into this, you can buy green beans and roast them yourself, but I screw that up so I buy roasted beans. Water is added to the ibrik, about 60 grams / 2 ounces. Put on low heat and wait until it gets frothy at the top, mixing occasionally. It should not boil - when it reaches the boiling point, the taste changes completely and it's ruined. The froth at the top has a particular name which I forget, but is considered the best part and should be served to guests. Whenever it starts foaming, remove from heat for a couple seconds and mix - repeat this a few times. When you drink it, whenever you feel the grounds (I believe they're called "zatz", unsure of spelling), let the coffee settle for a bit and try again. By now, you should realize that this is hardly "instant" coffee, but it's worth the effort.
Caffeine content is about 1.0 mg/g, compared to about 0.5-0.6 mg/g for filtered coffee, but the servings are smaller, so you're actually getting less caffeine but with much more flavor. Same idea as with Espresso, but this tastes good, not burnt.
That's completely incorrect. You're attempting to redirect two programs' i/o using file descriptor redirection. When you have two commands, you need a pipe. If you think about it, the reads/writes won't be synchronized, so you need some kernel mechanism to buffer the i/o: this is a pipe, fifo or socket.
Anyway, this still won't work as gpg does an isatty() on stdin when it asks for a password and then reopens the console if necessary. This is assuming you wanted the awk output as the password, as one can't really tell what you're intending to do. Also, the ".asc" extension means ascii-armored, so you want to use the "-a" flag. You're also confusing what "-s [filename]" means: "filename" is the input in this case.
Perhaps what you wanted is:
awk/\#/'{print $1,$2}'/etc/inetd.conf | gpg -a -s -o tradesekrits.asc -
Although this isn't very meaningful on any level if you examine the output of the awk command. Combined with the awkward shell quoting, I'm forced to assume your awk command doesn't do what you intend it to do. Perhaps you don't know what you're trying to say?
Two minutes, three lines of code, $10,000 - I'm undercharging my employer!
Seriously, though, don't run this without understanding each part. If you have a large network, split it up into separate commands using temp files. You'll probably want to add some code to check for self-signed certificates (assuming those aren't against your "corporate policy"). You'll also want to scan other ports running SSL directly, such as 995. Some services more commonly use STARTTLS in which case the openssl s_client won't work (LDAP v3, SMTP). For these services, you'll need to write a small network program linked to openssl that knows enough of the protocol to initiate STARTTLS and grab the certs. Overall, this is a half day of work at most for little programs to test all the STARTTLS possibilities.
I really have to question your company's judgment if they're willing to spend that much money on something so trivial. If you're large enough that rogue certificate servers actually pose a problem, you should definitely have some good *nix admin/network/systems programmer-types types who can do this for you.
Then I note that UNIX limits passwords to 8 bytes. A measly 64 bits.
Actually, crypt() throws away the high bits of each byte, leaving you with 56 bits. That's still enough. Using calculations from this previous post, using (what was advertised to be) the fastest current hardware it would take over 100,000 years on average to brute-force a randomly-generated password. So you should be plenty safe if you have a good password.
The number of bits in the key also mean something different in terms of security depending on what type of algorithm you use. Using public key algorithms like RSA with 256 bit keys is pretty stupid (2048 is considered a good number today), but 256 bit keys with a block cipher like AES is considered very secure.
I don't know where ECC ciphers fit in.
In crypt(), the 56 bits are used as a key to encrypting a known plaintext (zero string). This is how DES becomes a hash algorithm. With other password-hashing algorithms (MD5, SHA-1), there is no key, just plaintext and hashed result. The security of the algorithm isn't measured in bits as there is no key. If the algorithm is "good" the only way to get the password is to brute-force it and the length of the password determines how long this takes (assuming no dictionary passwords). Similarly, if DES is considered "good" (no attack other than brute force), the length of the password (which is the "key" in crypt()) determines how long brute force takes. Since crypt() uses a fixed-length key (56 bits) and from above we know how long it takes to brute force that, one would guess that it takes just as long to brute force MD5- or SHA-1-hashed passwords if the algorithms take a similar amount of time to run.
So there's nothing to worry about if you have good passwords.
The choice for the companies involved should be disclose the information for the spammer you hired or you get fined or criminally charged instead.
I love this. Great idea. Monumental.
We make the companies talk, and if they don't rat out their spammer brethren, we fine the company into the ground and maybe even throw some execs into the pen. This will surely end the spam problem: no way the spammer scum will find a way to turn this against us, like they did to Habeas or other anti-spam fighters.
On a completely different note, friends, I have an important message for my fellow slashdot readers:
MICROSOFT SERVER 2003
Microsoft Windows Server(TM) 2003 helps you do more with less. In the rapidly-changing world of corporate IT, you need to stay pro-active and think out of the box. With Microsoft Windows Server(TM) 2003, you can deploy Enterprise-ready applications faster and more securely, all the while reducing your TCO and increasing your ROI.
Where do you want to go today?(TM)
The spammers could flood the world with false spam runs targetting innocent companies, hiding their true money making runs, but I think those would stand out as the ones selling Viagra/Penis Patches/etc. as they do now.
There are legitimate companies that sell Viagra. I would guess that I could get Viagra at the corner Walgreens. But it would be obvious that the mom-and-pop viagra-selling shop advertised via spam actually supports spam, whereas when Walgreens is advertised via spam, it must be completely innocent because a large corporation would never do such a thing, right?
Similarly, when you get a spam advertising some shady stock deal, it's a "real" spam if it advertises some small trading shop, but it can't be a real spam if it advertises Morningstar.
If you think about it, legitimate companies can be easily identified: if they can afford extensive litigation, it's a legit company. Given this, we don't have to put any kind of qualifier on your original suggestion: any company advertised via spam should be forced to give information implicating spammers or face legal sanctions. Those few theoretically "innocent" companies can afford to protect themselves.
We can surely find the spammers if we presume people guilty with no evidence. Hey, it worked for finding the witches and the Communists, right?
It has been mentioned (repeatedly) that this is a trade school
curriculum, not a CS path. However, even as a trade school curriculum,
this seems pretty bad to me. I'll concentrate on the programming aspects of the curriculum rather than the administration bits (although I have reservations about those as well).
I once TAed a course on web programming to adults with little
background in programming. Whereas you split up web programming
into FOUR COURSES, we covered all that material in ONE COURSE. The
students had enough programming experience and concepts from other
courses that they were easily able to pick up Javascript, Perl,
Python, PHP, etc. We spent no time on HTML coding since students
were already familiar with other markup/meta- languages (even if
they didn't have experience with XML or EBNF, enough exposure to
programming should make learning HTML trivial).
Good programmers have a solid understanding of underlying architecture,
even if they program GUI or web applications in Python or Java.
You list no course on "Computer Architecture" or even "Assembly
Programming" (not the same thing but often combined in one course).
A course on "Compiler Architecture" should be central to any
curriculum, not only because it elucidates programming languages
through their implementations, but also because it's a perfect
example of melding programming with CS theory.
Instead of separate courses on Java, C++, C#, etc. you need to have
a single course on "Programming Languages" which is a survey course
of the various languages. This should be taken after an in-depth
study of programming in one language. The in-depth study will allow
the student to get into more "advanced" topics (in quotes because
I'd consider them rather basic) such as advanced data structures (such as B-Trees), Big-O/Theta/Omega notation,
hash functions, basic design patterns, loop invariants, etc. It
helps no one if you simply re-teach the same elementary topics again
and again but in different languages.
The programming language survey course would allow students to apply
already-mastered "advanced" concepts to new syntaxes and idioms.
The survey course should not simply showcase various procedural
programming languages (all the languages you list), but should also
include languages like Scheme or Haskell (functional programming),
ML (type inference and other type theory), Prolog (logic databases),
and perhaps something like Forth or Postscript. Students should
be able to take lessons learned from these more "esoteric" languages
and apply them to whatever they're doing (I use type safety lessons
from ML in my C, functional programming in my Perl and PHP, embedding
business logic into a database for end-user modification akin to
Prolog, and a stack is not some abstract but mostly useless example
from CS theory, but something that I actually use, thanks to
Forth/Postscript). If you try to teach functional programming in
C# or Javascript, students will have a difficult time following you
as these languages can certainly do some functional things but they
aren't designed for it, so it's not the right place to learn
functional programming.
Due to a solid background in OO theory and implementation, I was
able to pick up Objective C in no time at all when I first had to
do some Mac programming. Objective C takes a completely different
approach to OO programming and C++, Java or C#. I was able to
understand the difference between statically-bound and dynamically-bound
methods immediately because I know how vtables, etc. are implemented
in C++ and was able to extrapolate what a runtime binding system
could do for a C-like language from experience with functional
languages. Message forwarding posed no conceptual problems - it
just made sense. Although Java may now support introspection, you
won't find much use for it without dynamic binding, so I doubt Java
programmers can easily learn how to use that feature of their
language without at least some experience in Objective C or Smalltalk.
This is not some min
There's a reason operating systems are expensive. They are very complex programs that take a lot of time and effort to create. Why exactly do you feel that someone should put out an enormous amount of time and effort to create an operating system and then give it to you for free?
2) Simply send all your mail out through the box you get it in from. What's so hard about that?
That is not feasible for large numbers of users.
Say I want to send email using my work account from home. My ISP blocks outgoing port 25, as many ISPs do nowadays. I'm instead supposed to use my ISP's mail server. However, my mail is now assigned a spam score (or perhaps even rejected by some sites) since it originates from isp.com but is addressed from work.com.
Please don't tell me the solution is to VPN to work. That may work fine for some people, but what if I have several accounts in different domains? I get mail for the webmaster at a number of different domains, hosted by different people (each of which have other users so I can't set them up so they list my main work network as the legitimate sender). Is my mail client supposed to automatically set up a VPN to each mail server when I reply to a message using a certain address and each domain uses a different type of VPN (PPTP, IPSEC and various non-standard VPNs)? As a consultant webmaster, am I even trusted enough to be given access to their VPN?
Realistically, if SPF becomes widespread, it means that in many situations, users will no longer be able to concurrently use multiple email addresses from different domains. The problem will be exacerbated so that even two domains are difficult to work with as long as some ISPs block outgoing port 25. I've been following this SPF thing for some time now and nobody has given a good solution for this.
I don't have to deal with the port-25 blocking thing since I read all mail by sshing into a work machine (and I could probably hack my MTA to send mail using a different server based on from address), but I'll still have to deal with users for whom this is a real problem.
Slashdot Mirror
Absolutely. Sounds like a much more elegant way of doing things.
Quite a bit different, however. Certainly takes a different frame of mind and sounds like a different workflow as well.
I have a largish tree that's in dire need of some revision control. If things go as planned, it will be developed in multiple branches and will have automated remote checkouts (maybe even automated unit testing). I was just going to go with CVS, but I'm interested enough that I'll experiment with some of these new-fangled revision control systems. It looks like FreeBSD et al. will have a more difficult time changing systems, but I have a perfect opportunity for experimentation.
1. Why is this a bad idea?
2. What are these better methods for doing the same thing?
For those who don't know what we're talking about, this is the $FreeBSD: $ tag you see in source files. XFree86 also uses this as $XFree86: $. It basically replaces the $Id: $ or $Header: $ keyword.
Projects like FreeBSD need this because they maintain separate trees for a number of projects maintained by other people. They do this because:
It makes perfect sense that one would want to see what version a particular file is in FreeBSD's tree and in the project's tree.
Example (older tree):
So how do you do this with subversion?
I don't think you should.
OpenSSH has had a number of vulnerabilities over the past year. The situation is certain to improve now with privilege separation, but it's nonetheless the case that I spent time upgrading OpenSSH on a number of machines over the past year or two. The idea here is that perhaps some people haven't noticed that OpenSSH has had a number of vulnerabilities because they have to update their machines anyway, but I have a run of machines where the only thing I have to worry about is OpenSSH and remote kernel vulnerabilities (no local users, all custom network services) and I've noticed that OpenSSH has had a number of vulnerabilities and potential vulnerabilities.
Combine this with the fact that many newbies to Linux do not need SSH. One of the things I enjoy doing is working with *nix newbies (believe it or not) and many of them couldn't care less about accessing their machine remotely. Now these newbies are the same people who don't know how to turn off services and aren't subscribed to any vulnerability mailing lists, so they end up running something vulnerable and not knowing about it.
So, I don't believe you should qualify your statement in any way. All operating systems should default to listening on absolutely no ports after install. Turning on ssh is just a minor inconvenience for us, but having vulnerable machines on a network is a major PITA for everybody. You could make a case that ssh should be turned on if you're doing a network/headless install, but for a regular boot-off-CD/partition/format/install sequence, the only way the machine should respond is with RST, port-unreachable and echo-reply.
The only vendor I know of that's doing this correctly is Apple. The only network services they have on by default are portmap and netinfo and if you read their boot scripts, they plan to turn these off by default after they've dealt with some issues in 10.4. There may be some lesser-known Linux distros that do this as well, but you are correct in that the major distros turn on uneccessary services by default.
I hope you're joking.
Have you tried reading TAoCP? This is not some computer book but is an in-depth study of all the mathematics that Computer Science comprises. Some of the exercies would serve as topics for a PhD thesis (and are marked as such).
Suffice it to say that writing these books is not an easy task and I'm not sure if the series will ever get finished. I'm still on the first volume, so I don't know if I'll ever finish the series. Even though wikipedia shows us that a community effort can produce some good writing, I doubt it could ever produce something as in-depth as TAoCP.
And besides this, I think Addison-Wesley would have something to say about putting TAoCP in public domain.
I know of only one application that uses deflate but does not use zlib: putty (Windows ssh client). Excellent code, uses own zlib implementation partly to avoid monoculture, partly for other (very good) reasons.
Another culprit is OpenSSL. I'd REALLY like to see a nonrestrictive-licensed (BSD or public domain, not GPL) API-compatible OpenSSL alternative. In fact, I'm considering doing it myself, but I'm not fooling myself about how much work this is.
Other (smaller) examples: MD5. All code I've seen uses the same public domain MD5 implementation. The code is short enough that security shouldn't be an issue, but it's still a bit strange that everyone uses the same code when MD5 is a publicized Internet standard.
One really dangerous example is ASN.1. This is so horribly complex (commitee-designed) that nobody would want to implement an ASN.1 encoder/decoder when a public domain implementation exists, so everybody uses the same code. This is the code that caused those SNMP vulnerabilities a while ago: good example of code monoculture since it affected *nix, Windows and even embedded stuff like Cisco IOS.
One would normally not see this as the canonical form is:
This is faster as it does not need to send information between two processes using an IPC mechanism (the pipe) and it avoids unecessary computation ("grep filename" may be slower (depending on the grep implementation) than simple filename comparison a la fgrep).If you're actually going to use a regular expression to search for a file, the more common method is:
This avoids printing directories. Add '[^/]*$' to the end of the regex to avoid matches in directory names. Many versions of "find" (including Mac OS X "find") support a "-regex" option, but this is nonstandard.If your search allows it, even better is:
I'm not suggesting that you didn't know these things, but you can be certain that (due to the nature of the article) some *nix newbies will read your post and they may start doing those commands on a regular basis, not knowing of better alternatives, so one should be careful when posting these things to such a forum.For instance, one of my recent projects was writing a replacement GINA for Windows. This is the component that determines authorization, eg, the login window and associated logic. There were various that reasons existing products and projects were unsuitable. Microsoft's documentation is absolutely, incontrovertibly horrible (so incomplete that I get the distinct feeling it's intentionally meant to stop integration efforts). However, I managed to get through it by some reverse engineering (testing how various parameters affect a function) and some online research (third party websites, wine source when GPL is OK for the project).
What if Microsoft decides that I couldn't have done this without access to their source? There are only a few companies that write real GINAs without passing through actual login to MSGINA and I know some of them have access to source, so it may have been very helpful.
Obviously, I'm staying as far away from the leaked code as possible. In fact, I'm hesitant to even post to Slashdot as that might remotely associate me with some people that have the files or I might accidentally glance at a file listing or code snippet from some careless individual.
I'm not naive: I know that if I get taken to court, I'll be the one that has to prove that I never looked at the source. How the hell am I supposed to do that?
Even worse, a lot of the documentation I use comes from people who've reverse engineered it out of Windows. When I read something online, how am I supposed to know if it came from someone who truly reverse engineered it or from someone who had illegitimate source access? IAANAL (obviously) so this might even be OK legally, but I know that if Microsoft goes after me, I'll be destroyed due to their resources so I put little faith in the law (and Microsoft really hates people like me, I get people off of AD onto standard LDAP schemas).
Some of my other projects include remote filesystems via IFS and some various driver-level stuff. This really, really scares me. I spent days looking at hex dumps to get some things working. For a lot of projects the only way to test anything is a reboot, so I've put a lot of time into these projects and this leak gives Microsoft an opportunity to easily destroy all my work.
I'm seriously thinking of talking to a lawyer RIGHT NOW as I'd like to know exactly how I can protect my livelihood from now on and what steps I can take to gather evidence that I've never looked at Windows source.
How much do you think it's going to be in man-hours to have a programmer fix a bug in MS-SQL Server if my insanely complex budgeting query crashes the server?
Bad question. The answer is irrelevant since it won't happen: you have to wait for Microsoft to fix that bug, no matter how much the bug is costing you.
Open source software provides additional flexibility: if there's something wrong, you are not at the mercy of the vendor and can fix it yourself if it's important enough. Proprietary software does not provide this option.
How many people in the world even have the skill to do this within in a few days?
I routinely fix bugs in open source projects: I've submitted small bugfixes and feature patches to Patrick Powel of LPRng, the samba team, the ssh team and numerous small projects. Some of these smaller open source projects were even Windows system-level software written using all of Microsoft's worst practices like Hungarian, pointless typedefing and reserved fields for binary compatibility. I didn't throw myself into the Hell of Windows coding practices because it's fun, but because a particular project had bugs that were affecting deployment at work.
I'd like to think otherwise, but I'm not all that unique: I've met and worked with others with the right skills and background knowlege. The difference is that I'm motivated enough to spend a few hours finding a bug in someone else's code but many people wouldn't even consider it. Perhaps they once tried fixing something in Mozilla or KDE and were discouraged by the immense volume of code: the right place to start is some smaller (less glorious) project, or perhaps something very segmented like the Linux kernel (which I've found to be very friendly to modification).
I think you'll find more and more people able and willing to make source modifications as you gravitate toward open source: like I said, Windows programming (Platform SDK, MFC) is hellish, and it discourages any kind of programming.
Don't forget the visual DOM inpector. Inspired me to clean up some nested table madness over the weekend on sites that would have otherwise remained unmanageable indefinitely.
Also, why isn't live-header part of the default install (at least the "view page info" tab, not necessarily the menu item)? It's ridiculous that I have to run a sniffer to do simple web development when some cache control issue comes up (and lots of good a sniffer will do you when you have to keep the site behind ssl - sure, openssl s_client/s_server can help, but toggling between the two gets old fast). I really don't understand how browser writers could have missed such a simple feature for so long - analagous to a MUA that doesn't have a "view headers" option. Don't get me wrong, I don't mind installing an extension, but this feature is long overdue.
For extra fun, try viewing the headers Slashdot sends (X-Bender, X-Fry).
More flexible and better from a usability standpoint.
I'm sure we've all received a call from some hopeless soul whose "screen was half gray" because they accidentally dragged the taskbar halfway up the screen. Thus, Windows XP default theme turns off taskbar dragging by default.
Similarly, I've seen MSIE setups where the user has accidentally dragged the address bar above the menu bar or put the menu bar at the extreme right so only "File >>" is showing. They then ask who deleted their bookmarks. Thus, IE 6 has a "Lock the Toolbars" option (unfortunately off by default, but I'm willing to be hard cash it will be on (or toolbars will otherwise be non-draggable) by default in Microsoft's next major browser/OS revision).
Don't even get me started on Microsoft Word and mortified secretaries who can't save because the floppy icon disappeared.
Simple usability lesson is "avoid accidental customization." I find it very unfortunate that GTK and KDE were so quick to adopt Microsoft's perpetually draggable menubars/toolbars. A simple right-click/control-click (or even a menu item to call up a toolbar editor) is more than sufficient and intuitive enough for those who actually want to customize their toolbars.
Now wouldn't it be nice if malicious code could only be run by those who know how to bypass fascist security restrictions? :)
I'd say noexec buys you something if you can only run a new program after going through a specific process. Namely, you know you're running a new program. I can deal with my users' maliciousness, but my users' foolishness keeps me up at night.
First, the plural of virus always has been "viruses".
Secondly, if I get an ELF executable in an email, I have to save it to disk, open a terminal, chmod +x it and then type in its name. Double-clicking on a saved executable in a file manager will probably do something like open it with a text editor until you've made it executable.
It might be a little easier if you send an RPM file in email, but then the user opens the file and is asked "Are you sure you want to install package 'such-and-such'?" by the friendly rpm gui manager. Even then, unless the user provides an administrative password (assuming the machine is running some kind of backend gui authenticator like ksudo for KDE or the Security Services API in Mac OS X), there is no way any kind of software can install itself systemwide so it starts on boot, but only to start on login (granted, this makes little difference on a single-user machine).
With these things in mind, you can very easily lock down a system so even this rpm-on-login exploit is impossible if you mount home directories (and /tmp) no-exec. This flag has been standard in Unix variants for a long time and is often used for stuff like NFS-mounted mail spools. It even works in Mac OS X and I've successfully used it for this purpose on specialized kiosk-type applications. This prevents certain users from writing their own programs and scripts, but hopefully one would feel comfortable granting an exception for these more advanced users and giving them some space for programming.
I have a method for identifying legaleze, or for that matter, anything written by a lawyer: count the number of times the document uses "in the event that" and compare to the number of times it uses "if". "In the event that" is pure, useless verbiage which can in all circumstances be replaced with "if". It's simply poor writing and is not more "clear" or "exact" than "if", but I guess it's ingrained in lawyer culture, so they continue to use it.
This document uses "in the event that" ten times, but uses "if" over eighty times. Looks like wannabe legaleze to me.
Indeed, if you look at the bottom of the document, you'll find this:
I guess my point is that this isn't as funny as you would think: if it were an actual lawyer writing this, it would show just how bad things have become around here, but it's not some lawyer, just some random loony.Another possibility is that this man has just pulled off the most masterful troll in the history of the Internet by fooling thousands of Slashdot readers into rightful indignation. However, the document seems serious about some of the provisions about copying images, so this might not be the case. On the other hand, these more plausible sections may have been added specifically to ward off trollbusters.
In any case, take it with a grain of salt. You might end up looking foolish if you say that this signals the end of American civilization.
what colleges im going to apply to
I'm not going to get into stylistic subtleties here ("what" instead of "which", preposition "to" separated from its object, using "but" twice in the same sentence with differing puncutation). Instead, I'd like to remind you that the first person singular pronoun is always capitalized in English and that contractions contain apostrophes. I've attempted to read your blog, and you are no e. e. cummings, sir. The poet I mention had very specific justifications for his capitalization, laziness and ignorance not being among these reasons.
Here's another viewpoint.
I was hoping to find a college with a major, along the lines of Network Engineering, but I have yet to find one.
The comma is commonly used to separate clauses which supply extraneous information. Let's see how well your sentence stands without it:
I was hoping to find a college with a major, but I have yet to find one.
Indeed.
Slashdot is not an instant messaging program. Your words were read by thousands of people. You should at least attempt to demonstrate a mastery of the language you've been using since shortly after your birth. After all, if you present enough of a communication barrier to your superiors, they won't have any qualms looking to the Far East for their engineering.
Point well taken.
I think the naysayers are those people who do not understand passion. In this case, it's a passion for understanding and controlling every minute detail of a machine, but anyone who is passionate about something - be it music, writing, mountain climbing or even font design or organic chemistry - can understand the motivation. I'm not really into performance cars, but I think I can understand the drive behind the hotrodders who try to tweak every last bit of performance out of their machines.
Sadly, I find few people who demonstrate passion. It seems like most people would rather have me bug-fixing drivers for their new-fangled 3-d video card than writing a window manager for my own use, just like most people would rather have their brake pads changed by the hotrodders instead of leaving them in peace.
I've found some solace in open source communities as they seem to attract a higher-than-usual percent of people who understand passion, both programmers and users.
Not true at all. In fact, I couldn't care less about spyware transmitting information. When I start to care is when I get a call because someone's machine is malfunctioning.
I've seen numerous spyware hijack IE, replace the startup page, install IE extensions to randomly popup advertisements, change how DNS resolution works, etc. I've seen machines where it takes minutes to start up a browser.
I highly recommend Kerio firewall, by the way; it's free as in beer and quite full-featured.
Kerio is trivial to bypass if you bypass the winsock API and program directly to NDIS. I've done this as a demonstration only, but seeing how spyware is so pernicious, I bet you'll soon see spyware doing the same things.
Application-level firewalls are useless if the user has full access to the machine. If the user has the ability to bypass the firewall, a program can do so just as easily and there is no way in Windows to differentiate between messages coming from keyboard/mouse and messages coming from other applications. Similarly, these are useless if the user has the ability to choose whether a program is put in the firewall's "allowed applications" list, as a malicious program can simply fake the user input and put itself there; on the other hand, taking away this ability from the user is not something I'd like to do, as my users should be free to use Mozilla, Opera or any other browser they choose without going through me.
I think we're talking about different things: I'm not concerned about keeping spyware off of my personal workstations, as these machines never get spyware in the first place due to me being careful about what I run. What I care about is keeping employee machines spyware-free while at the same time allowing users to install their own applications without going through me.
Actually, the situation is exactly the same as with viruses: I don't worry about viruses on my personal machines, but I know my users aren't sophisticated enough to differentiate between an attachment called "file.doc" and "file.doc [fifty spaces] .exe", so I install antivirus software on their machines. Similarly, I know they're going to download and execute spyware, so I'd like some tool that runs in the background recognizing spyware and preventing it from running. The paid version of adaware does this, and I consider it a virus scanner that stops viruses written by questionably-legitimate companies instead of individuals.
So there is a place for anti-spyware tools: if you're a sophisticated user on your own machine, you can do without antispyware software, but if you're in a situation where antivirus software is warranted, antispyware software is also a good idea. I just wish McAfee would stop pandering to these spyware "companies" so we wouldn't have to get two site licenses for similar software.
Anyway, I'd recommend doing a google search for 386intel.txt. This is Intel's documentation for the 386 chip, including systems programming stuff. This is the file Linus used. The modern version of this documentation is available here for the Pentium III, split up in three. You'll need all three, but the third in the series is most relevant.
After you get booting, you'll need some documentation for various devices when writing drivers. I used "The Indespensible PC Hardware Book" by Messner and it was pretty good. I guess there are also good websites available and you can always look at how Linux or *BSD does it.
Anyway, you might be able to skip the Intel documentation if you use someone else's bootloader, but I don't recommend this. One of the points of this project should be to understand the machine inside and out from boot, so write your own bootloader and object code loader. Once it can run your C code, you'll get a feeling of satisfaction, which should be another of this project's goals.
I used an older version of VMWare for testing, but I highly recommend bochs nowadays. Bochs seems designed exactly for this stuff, so you can run a debugger right away and you don't need to go through the older debugging route which was to write a serial port driver as soon as possible and get a remote debugger working over that (easiest way to do remote debugging in VMWare and real hardware).
I'd recommend nasm for the assembler bits. It can do 16-bit code for the bootloader and it can spit out unadorned object code so you don't have to bother with parsing ELF and extracting what you need (although you'll need to do this eventually when you get to C, but you can at least delay that until after you start booting).
One last thing - ignore the naysayers. It seems lots of people thought it important to post that you shouldn't be doing this but should instead be contributing some drivers to another project or something like that. Whenever someone in the open source community says this, they're almost always non-developers. Most of us write code on our own time because we find it satisfying and this is one of the most satisfying projects you can undertake. This project is also a kind of "coming-of-age" experience (for lack of a better word), like writing your own compiler or creating a GUI API or window manager. Users won't understand. That's OK. We understand.
For the uninitiated: this is pure, unfiltered coffee. A small flask-shaped pot (called an "ibrik") is filled with one heaping teaspoon of coffee for each serving and one half teaspoon of sugar to taste. The coffee must be ground to a fine powder or the flavor won't be extracted, and for maximum flavor, you must buy beans and grind them yourself (don't let the powder sit for too long). If you're really into this, you can buy green beans and roast them yourself, but I screw that up so I buy roasted beans. Water is added to the ibrik, about 60 grams / 2 ounces. Put on low heat and wait until it gets frothy at the top, mixing occasionally. It should not boil - when it reaches the boiling point, the taste changes completely and it's ruined. The froth at the top has a particular name which I forget, but is considered the best part and should be served to guests. Whenever it starts foaming, remove from heat for a couple seconds and mix - repeat this a few times. When you drink it, whenever you feel the grounds (I believe they're called "zatz", unsure of spelling), let the coffee settle for a bit and try again. By now, you should realize that this is hardly "instant" coffee, but it's worth the effort.
Caffeine content is about 1.0 mg/g, compared to about 0.5-0.6 mg/g for filtered coffee, but the servings are smaller, so you're actually getting less caffeine but with much more flavor. Same idea as with Espresso, but this tastes good, not burnt.
OpenBSD is a proper noun with no space in it.
sed 's/^/\#/g' /etc/inetd.conf >> /tmp
I believe that's supposed to be:
In older variants of Unix, what you did would have been allowed and it would have corrupted the directory entries forawk /\#/'{print $1,$2}' /etc/inetd.conf < gpg -s tradesekrits.asc
That's completely incorrect. You're attempting to redirect two programs' i/o using file descriptor redirection. When you have two commands, you need a pipe. If you think about it, the reads/writes won't be synchronized, so you need some kernel mechanism to buffer the i/o: this is a pipe, fifo or socket.
Anyway, this still won't work as gpg does an isatty() on stdin when it asks for a password and then reopens the console if necessary. This is assuming you wanted the awk output as the password, as one can't really tell what you're intending to do. Also, the ".asc" extension means ascii-armored, so you want to use the "-a" flag. You're also confusing what "-s [filename]" means: "filename" is the input in this case.
Perhaps what you wanted is:
Although this isn't very meaningful on any level if you examine the output of the awk command. Combined with the awkward shell quoting, I'm forced to assume your awk command doesn't do what you intend it to do. Perhaps you don't know what you're trying to say?Two minutes, three lines of code, $10,000 - I'm undercharging my employer!
Seriously, though, don't run this without understanding each part. If you have a large network, split it up into separate commands using temp files. You'll probably want to add some code to check for self-signed certificates (assuming those aren't against your "corporate policy"). You'll also want to scan other ports running SSL directly, such as 995. Some services more commonly use STARTTLS in which case the openssl s_client won't work (LDAP v3, SMTP). For these services, you'll need to write a small network program linked to openssl that knows enough of the protocol to initiate STARTTLS and grab the certs. Overall, this is a half day of work at most for little programs to test all the STARTTLS possibilities.
I really have to question your company's judgment if they're willing to spend that much money on something so trivial. If you're large enough that rogue certificate servers actually pose a problem, you should definitely have some good *nix admin/network/systems programmer-types types who can do this for you.
Actually, crypt() throws away the high bits of each byte, leaving you with 56 bits. That's still enough. Using calculations from this previous post, using (what was advertised to be) the fastest current hardware it would take over 100,000 years on average to brute-force a randomly-generated password. So you should be plenty safe if you have a good password.
The number of bits in the key also mean something different in terms of security depending on what type of algorithm you use. Using public key algorithms like RSA with 256 bit keys is pretty stupid (2048 is considered a good number today), but 256 bit keys with a block cipher like AES is considered very secure. I don't know where ECC ciphers fit in.
In crypt(), the 56 bits are used as a key to encrypting a known plaintext (zero string). This is how DES becomes a hash algorithm. With other password-hashing algorithms (MD5, SHA-1), there is no key, just plaintext and hashed result. The security of the algorithm isn't measured in bits as there is no key. If the algorithm is "good" the only way to get the password is to brute-force it and the length of the password determines how long this takes (assuming no dictionary passwords). Similarly, if DES is considered "good" (no attack other than brute force), the length of the password (which is the "key" in crypt()) determines how long brute force takes. Since crypt() uses a fixed-length key (56 bits) and from above we know how long it takes to brute force that, one would guess that it takes just as long to brute force MD5- or SHA-1-hashed passwords if the algorithms take a similar amount of time to run.
So there's nothing to worry about if you have good passwords.
I love this. Great idea. Monumental.
We make the companies talk, and if they don't rat out their spammer brethren, we fine the company into the ground and maybe even throw some execs into the pen. This will surely end the spam problem: no way the spammer scum will find a way to turn this against us, like they did to Habeas or other anti-spam fighters.
On a completely different note, friends, I have an important message for my fellow slashdot readers:
The spammers could flood the world with false spam runs targetting innocent companies, hiding their true money making runs, but I think those would stand out as the ones selling Viagra/Penis Patches/etc. as they do now.There are legitimate companies that sell Viagra. I would guess that I could get Viagra at the corner Walgreens. But it would be obvious that the mom-and-pop viagra-selling shop advertised via spam actually supports spam, whereas when Walgreens is advertised via spam, it must be completely innocent because a large corporation would never do such a thing, right?
Similarly, when you get a spam advertising some shady stock deal, it's a "real" spam if it advertises some small trading shop, but it can't be a real spam if it advertises Morningstar.
If you think about it, legitimate companies can be easily identified: if they can afford extensive litigation, it's a legit company. Given this, we don't have to put any kind of qualifier on your original suggestion: any company advertised via spam should be forced to give information implicating spammers or face legal sanctions. Those few theoretically "innocent" companies can afford to protect themselves.
We can surely find the spammers if we presume people guilty with no evidence. Hey, it worked for finding the witches and the Communists, right?
I once TAed a course on web programming to adults with little background in programming. Whereas you split up web programming into FOUR COURSES, we covered all that material in ONE COURSE. The students had enough programming experience and concepts from other courses that they were easily able to pick up Javascript, Perl, Python, PHP, etc. We spent no time on HTML coding since students were already familiar with other markup/meta- languages (even if they didn't have experience with XML or EBNF, enough exposure to programming should make learning HTML trivial).
Good programmers have a solid understanding of underlying architecture, even if they program GUI or web applications in Python or Java. You list no course on "Computer Architecture" or even "Assembly Programming" (not the same thing but often combined in one course). A course on "Compiler Architecture" should be central to any curriculum, not only because it elucidates programming languages through their implementations, but also because it's a perfect example of melding programming with CS theory.
Instead of separate courses on Java, C++, C#, etc. you need to have a single course on "Programming Languages" which is a survey course of the various languages. This should be taken after an in-depth study of programming in one language. The in-depth study will allow the student to get into more "advanced" topics (in quotes because I'd consider them rather basic) such as advanced data structures (such as B-Trees), Big-O/Theta/Omega notation, hash functions, basic design patterns, loop invariants, etc. It helps no one if you simply re-teach the same elementary topics again and again but in different languages.
The programming language survey course would allow students to apply already-mastered "advanced" concepts to new syntaxes and idioms. The survey course should not simply showcase various procedural programming languages (all the languages you list), but should also include languages like Scheme or Haskell (functional programming), ML (type inference and other type theory), Prolog (logic databases), and perhaps something like Forth or Postscript. Students should be able to take lessons learned from these more "esoteric" languages and apply them to whatever they're doing (I use type safety lessons from ML in my C, functional programming in my Perl and PHP, embedding business logic into a database for end-user modification akin to Prolog, and a stack is not some abstract but mostly useless example from CS theory, but something that I actually use, thanks to Forth/Postscript). If you try to teach functional programming in C# or Javascript, students will have a difficult time following you as these languages can certainly do some functional things but they aren't designed for it, so it's not the right place to learn functional programming.
Due to a solid background in OO theory and implementation, I was able to pick up Objective C in no time at all when I first had to do some Mac programming. Objective C takes a completely different approach to OO programming and C++, Java or C#. I was able to understand the difference between statically-bound and dynamically-bound methods immediately because I know how vtables, etc. are implemented in C++ and was able to extrapolate what a runtime binding system could do for a C-like language from experience with functional languages. Message forwarding posed no conceptual problems - it just made sense. Although Java may now support introspection, you won't find much use for it without dynamic binding, so I doubt Java programmers can easily learn how to use that feature of their language without at least some experience in Objective C or Smalltalk. This is not some min
There's a reason operating systems are expensive. They are very complex programs that take a lot of time and effort to create. Why exactly do you feel that someone should put out an enormous amount of time and effort to create an operating system and then give it to you for free?
That is not feasible for large numbers of users.
Say I want to send email using my work account from home. My ISP blocks outgoing port 25, as many ISPs do nowadays. I'm instead supposed to use my ISP's mail server. However, my mail is now assigned a spam score (or perhaps even rejected by some sites) since it originates from isp.com but is addressed from work.com.
Please don't tell me the solution is to VPN to work. That may work fine for some people, but what if I have several accounts in different domains? I get mail for the webmaster at a number of different domains, hosted by different people (each of which have other users so I can't set them up so they list my main work network as the legitimate sender). Is my mail client supposed to automatically set up a VPN to each mail server when I reply to a message using a certain address and each domain uses a different type of VPN (PPTP, IPSEC and various non-standard VPNs)? As a consultant webmaster, am I even trusted enough to be given access to their VPN?
Realistically, if SPF becomes widespread, it means that in many situations, users will no longer be able to concurrently use multiple email addresses from different domains. The problem will be exacerbated so that even two domains are difficult to work with as long as some ISPs block outgoing port 25. I've been following this SPF thing for some time now and nobody has given a good solution for this.
I don't have to deal with the port-25 blocking thing since I read all mail by sshing into a work machine (and I could probably hack my MTA to send mail using a different server based on from address), but I'll still have to deal with users for whom this is a real problem.