This is a non-issue, mostly.

If you want to filter traffic, and maintain any level of control, first block all internet traffic from computers. Then set up filtering proxys on the application level, for the protocols you want to grant access to. Yes, that means that when a 10 year old hacks your squid-guard machine, she'll be able to steal teachers credit card numbers. But then 8 year olds already had them, because they'd installed hardware keyloggers on a few select pcs...

The fact that it's possible to block/manipulate plaintext protocols is just a bug -- not a feature. Just look at all the sites that still use plain http for login.

You'd still need to monitor for unauthorized wireless lans, student cellphones etc. Most schools I know of don't allow students to use cellphones in class, I see no reason why SSL-traffic shouldn't be limited/filtered in order to provide fewer distractions during class.

Have the firewalls open up all traffic during breaks/lunch hour and/or the application proxies enable xmmp during those times -- or have a simple front end for each vlan/subnet (ie: classrom) where the teacher can select between no-filtering/blacklists+content filter/whitelists.

For good arguments about *why* a school might want to filter/restrict traffic see: http://yro.slashdot.org/comments.pl?sid=1693516&cid=32649110

No, the modern way of doing scripting in Windows is install Bash, Perl or Python. Powershell is to modern as cat is to dog.

Umm, no. Powershell is to modern as more is to less?

Well, you could start with a "hello world!" operating system:

    http://www.vpri.org/fonc_wiki/index.php/XO_Hacking

Seriously, it's a lot easier to build a bomb that can kill a few thousand civilians (air burst fuel-air explosives anyone?), than a rocket that can take out a stealth UAV before it's able to take you out.

On the other hand, if the "bad guys" had access to real weapons, maybe they'd kill some politicians, generals and CEOs rather than infantry and civilians (on "both" sides) ...

Now, this looks very interesting. It's got nothing do to with wave -- except -- it might be nice to implement wave support for Raindrop ? Before looking at the raindrop source, it's hard to tell -- but from the videos it appears Raindrop handles i/o along several protocol streams, along with a seperate ui.

Stands to reason it should be feasable to implement a wave-backend -- the question then would be if the best way to handle that was encourage widespread wave-server-federation (every couchdb/raindrop-instance it's very own wave server) -- or connect the raindrop-backend to standalone wave-server(s) (more like how email is presumably handled by raindrop).

http://code.google.com/p/wave-protocol/wiki/Installation ?

I like the idea of wave to a certain extent -- but I'm sceptical about the architecture. For IM/collaobration sure -- but as a *replacement* for email/news ? Email is pretty much bulletproof, with failover, handling of temporarily downed servers etc straight out of the box.

Wave (as a protocol) seems far less scalable.

Hm, don't be so sure. At least the exploit vector that leaped out at me was booting the machine, pulling
the sims, cooling them off with some dry ice, while reading them in another machine... not sure if anyone tried that for attacking bitlocker -- but it sounds like a great science project to try to find
the encryption keys for the hd.

Failing that, are these systems vulnerable to attack via firewire?

Voted sed, as it can do the work of cat and grep, in addition to being useful in it's own right. But really (with the exception of find and sed) none of the other are much use without the shell's pipe functionality...

Ofcourse they do. It's a lot easier to work with the (in almost all cases) original electronic text than the printed form. It's why word processors are so popular. Personally I'd prefer Vim and (La)TeX -- but the fact remains that most written works from the 90s onwards has something that could very well be described as source text (I agree, it's not really code, not even if it's in plan TeX).

How about: http://diveintopython.org/ ? And depending on your definition of "available in print": http://www.lulu.com/browse/search.php?fKeywords=gnu (along with pretty much any book available in ps/pdf/tex that you can print for yourself at lulu, licence permitting...).

Also found this which is available as a gratis download, and might be of help to the original poster:

http://www.lulu.com/content/paperback-book/intro-to-computers/2230846

I'm sure you could find a version of http://www.forth.org/ to work on this machine. I recently (re)discovered this nice little language/environment and one of my summer projects is to learn more... Forth traditionally lives on a floppy, merging code and data in a way similar to Smalltalk images.

It's an efficient language, and pretty fast -- sometimes faster than C. It's essentially a "different" way to write structured assembly from what C is...

You might even be able to port openfirmware to you platform, and, with a bit of work, run forth directly from BIOS!

As others have suggested, being able to load code from the serial or parallel port might be the way to go... or you might be able to get an old harddrive to work?

See also: http://www.classiccmp.org/dunfield/img/index.htm

Good luck!

Erm, from tfa:

"3rd step: Compensating Participants

All income in the company (minus operating expenses), will be passed through the trust metric and distributed to participants."

So, no ... not "without the paycheck". Without the job security, the pension plan, the medical coverage -- true. But in theory if operating costs are low enough the average worker should be able to make more than in any other reward-model.

Making the (not insignificant) assumption that the company is actually profitable.

I recently installed Debian on an old Laptop for a friend. The machine has 64Mb of ram and a 600Mhz cpu. It boots in about a minute to the Enlightenment Desktop I set up as autologin via GDM.

That was with parallell boot and a few trick -- but I don't think that made much difference.

However, restoring from hibernate-disk (ie from power completely off) was insanely fast, maybe as much as 10 seconds to destkop -- and ofcourse if you leave the browser up, then you're truly ready to go.

Due to the low ram, I installed epiphany rather than firefox.

Btw, this is also with encrypted disk, and the time to enter the password is factored in.

I see little reason to run ubuntu rather than Debian -- but then I've been running Debian since potato a while back. I've been using Ubuntu since the first LTS release -- and I'm sorry to say I personally find Debian's Stable/Testing/Unstable-trinity much better than the rushed feeling, and short support for Ubuntu releases.

Debian ofcourse benefits from Ubuntu's resources and testing -- so I'm glad it exists -- I just prefer Debian. Debian also seems to scale down much better than Ubuntu.

I now run the 64bit version of Debian/Lenny on my desktop with 2cores and 8Gb of ram -- the same version that worked flawlessly on the ageing laptop (but in 32bit for obvious reasons).

The laptop had a whopping 6GB of disk, btw, less than my worstation's RAM...

So, in other words -- you also distribute javascript that would be practically useless as a startingpoint for modifications, bugfixing etc.

Free javascript does this too -- jQuery and the Yahoo!-tools all have a "for developers" and a "for distribution"-version.

While I haven not RTFA yet -- the point is that when you introduce a bug in your compressed, unreadable to the end-user code, say leaking passwords or cookies over plain http -- there's very little the end-user can do -- weather he/she knows javascript or not.

Now, if you have a link on your page with a Free copy of the scripts you use, along with an algorithm for distributing the "compact" version -- then, given some more improvements to the "normal" web 2.0 architecture -- anyone could fix your bug, and supply you with a patch.

If you accidentially run over someone with your car, or shoot them in cold blood they'll be just as dead -- regardless of your motives.

If you distribute unreadable, unmaintainable code, it would be reasonable to call that code obfuscated -- even if you had a good and noble reason to obfuscate (compress) it.

So, we can assume, that if any intelligence organization today breaks eg. skype encryption, they might go to great lengths in publicizing the service as secure ?

Say, by making it appear that national and international police is unable to tap it efficiently, and starting a long-winded bureaucratic process "allowing" police access ?

Oh, I don't know. According to
http://thepiratebay.org/top/201 (top 100 movies)
69 appear to be dvd rips, and a total of 85 are dvd rips OR screener rips.

24 appear to be from 2009, while 61 are from 2008 -- at least 1 half months old.

So, no most of the top 100 films are not "fresh out of the theater".

Maybe you shouldn't just make up facts that can be *easily* checked ?