Actually if he's connected to a Jabber server and that server is connected to the internet, he can talk to anyone on any internet-connected Jabber server. Kind of remniscent of SMTP servers connecting to remote servers when necessary, although the mechanism is a bit different.
Packet isn't terribly popular (since most ham bands are positively dominated by FM or SSB voice), and the bandwidth is absolutely abyssmal. Prices of 1200 baud TNCs (the packet radio equivalent of modems) are in the 100-200 US dollar range. 9600 baud to 19.2 kilobaud are outrageously pricey. In other words, it's unlikely that you'd be able to get any useful bandwidth for a reasonable price.
On the other hand, it turns out that 802.11b channel 1 is within the ham band. This means that, as a ham, you can use this channel under FCC part 97 instead of unlicenced FCC part 15. In other words, as long as you broadcast your callsign every ten minutes (say as the contents of an ICMP packet or the essid), you can legally use up to 1 watt and drown out all neighbouring signals. Additionally, there's no question of the legality of using high gain directional antennae as long as don't exceed one watt peak output power.
Sounds very similar to my laptop (Sharp Actius MM10, only link I could find is this review). It's super small, super light, good Linux support, and totally awesome for doing non CPU-intensive applications (like programming). It has the the same key layout with fn-left for home, which I've come to miss on almost every other keyboard I've ever used. I've also been spoiled with long battery life since I got the nine hour for this guy. Considering my current machine was last produced in 2003, it sounds like the sony may be a very reasonable machine to upgrade to.
That said, have you run into any downsides with it? Keep in mind I'm used to most of the limitations of a tiny laptop.
Normally I say don't feed the trolls, but hot damn, it's nice to hear someone with a pair of balls in the midst of all the political correctness bullshit we deal with daily. Good show, sir.
as just one silly example, it would suck if you wouldn't be able to explicitly close a file, because you can't delete it before it's closed
Just to nitpick, I've never seen this problem on any modern operating system I've used. On the Unix-like ones, calling unlink on a file name will remove that file from the file system. If any process still has open descriptors for it, the data will be retained until those are freed by manually calling close or when the process exits.
I suppose this could lead to a problem if one has a long running process holding onto descriptors for huge files, but you seem to imply that they'll be freed eventually anyway. Anyway I don't mean to troll, just have nothing better to do on a saturday morning than nitpick!
It's an interesting concept, and I've thought about trying to use the fairly dense wifi network access outdoors in an effort to move data (GPS, etc) between my vehicle and my home.
You may be interested in this gentleman's setup. It's somewhat light on details, but it proves that it definitely can be done.
This occurs when the file system is not mounted with the sync option [which is the default, unless there is something in the fstab that says otherwise]. Most modern Linux distros I've seen have an entry in the fstab with something along the lines of noauto,rw,user,sync. That way, an ordinary user who has read/write access to the floppy device node will be able to mount and unmount it, and it will auto-sync as soon as files are copied.
A sibling post mentions that the default non-sync behaviour can lead to the mv problem that the article boils down to. Perhaps you should make sure you mount your external media with sync just to be sure there won't be a problem.
You never know who might be going through your trash, piecing together private information.
Quoted for truth! A few years ago some kids got a hold of my garbage file and managed to frame me for something called a Da Vinci virus! It was awful, even Angelina Jolie was somehow involved.
I feel you man. It's the very definition of evil when people who are providing you with an incredibly large amount of free resources seek a little remittance for it now and then.
So, these media firms have lost a faithful, paying customer.
Another poor soul deluded into believing he's the customer. Here's a tip: when you're sitting there forced to watch adverts on the disk over which you cannot skip, you're not the customer: you're the consumer.
And by the way, that's just a euphemistic way of saying that you're the product.
If you're on a unix system, there are two very nice browsers that I know of:
Dillo runs on X and uses gtk 1.2 as a toolkit [oldschool]. It doesn't have a lot of features [hell, it doesn't even do CSS], but it's the leanest, fastest graphical browser I've ever used that integrates at all with other X applications.
Links2 runs in the terminal or [with the -g options] under X. The X version is ugly and doesn't integrate with other X apps, but it works incredibly well and even has support for some more advanced features like Javascript, which of course can be disabled if you like. I frequently run links2 on my laptop with limited memory and, while it may not be as pretty as Firefox, it definitely gets the job done more than 95% of the time.
I suppose my understanding of OpenVPN must only be applicable to an older version in that case. I'll read into the source a bit more on that, but I do stand corrected.
The whole idea of needing to get the entire stream to decrypt it is absolutely correct. However, it depends on what you define as the ``whole stream''. In the case of SRTP, they define each UDP packet as an entire, distinct stream. In fact, SRTP does not define usage with any stream cypher. The only cypher it allows in the spec is AES [a block cypher] operating in special modes similar to CBC [output feedback or some strange variation on counter] with each packet representing a single stream.
SSL isn't any sort of cypher, it is a suite of crypto tools. The things people most often use it for are public key encryption [usually with RSA] and symmetric encryption. For the latter, an implementation may provide any number of block cyphers operating in various modes that effectively make them stream cyphers. For what it's worth, the only widely used strictly stream cypher is RC4 and I don't hear about it being used much outside of WEP/WPA (although SSL implementations do typically include it for completeness and backward compatibility).
Unless it's changed drastically recently, OpenVPN uses SSL to encrypt each UDP packet. It uses one of SSL's block cyphers in a streaming manner and treats each packet as a distinct stream. That way, it can be decrypted independently of other packets and injected into the tun/tap device on the remote end.
SRTP works in a similar manner, although you are correct in that it doesn't use SSL. Since UDP packets are meant to be semi-independent, both OpenVPN and SRTP have certain issues to handle, such as anti-replay measures and such, but both protocols define ways of handling this and are both quite secure in practise.
Skype probably using some timing measures to prevent the user from attaching a debugger, and ltrace may alter the timing enough so that Skype believes this is the case. If you're outputting the ltrace debugging to the terminal, that could very well be the case, because terminal output is pretty slow. Maybe outputting it using the -o flag would make it work. I don't use Skype, otherwise I'd try myself.
Apple does have the home turf advantage of having the source to OS 9. Not to mention, Apple isn't afraid of deprecating and even making old software obsolete. Versions of OS X running on Intel Macs do not have support for Classic applications, and most of their customers simply don't care. Microsoft is stuck supporting legacy code written for 16 bit versions of Windows right next to the latest and flashiest modern apps.
It's a different business model with a different customer base. Unfortunately, those who are on the sidelines trying to implement a mostly undocumented API are stuck with what they can reverse engineer. That leads to a project that is admittedly less polished than one where the source of the API being implemented is available.
So does GNOME. It's called GConf and it stores data hierarchically not too much unlike the Windows registry. Much like an LDAP server, the frontend has a unified API, but the backend can be any data store. The default is XML files in/etc/gconf, but nothing prevents you from storing it in a legit RDBMS. There are libraries for accessing it in most languages, as well.
Why didn't it catch on? Most [all?] GNOME projects use it now, and a handful of others do. I'm sure the Qt mirror-mirror version of GConf is much the same for KDE apps.
Why wouldn't I use it? Why bother with forcing the user to have another dependency when a dotfile is more than good enough for a standalone console app. In a more perfect world, where I could count on the user having GConf or Qt's version, maybe it'd be different. But for now, I'm afraid I have to stick to a simpler text file configuration for most things, which unfortunately means one parser per app.
Slashdot Mirror
Actually if he's connected to a Jabber server and that server is connected to the internet, he can talk to anyone on any internet-connected Jabber server. Kind of remniscent of SMTP servers connecting to remote servers when necessary, although the mechanism is a bit different.
But what if you have some strange interest in funky keyboard layouts?
From the page you linked:
2.4 GHz (spread spectrum i.e. 802.11 or 802.11b): 1 watt w/o using automatic power control (per 97.313)
Packet isn't terribly popular (since most ham bands are positively dominated by FM or SSB voice), and the bandwidth is absolutely abyssmal. Prices of 1200 baud TNCs (the packet radio equivalent of modems) are in the 100-200 US dollar range. 9600 baud to 19.2 kilobaud are outrageously pricey. In other words, it's unlikely that you'd be able to get any useful bandwidth for a reasonable price.
On the other hand, it turns out that 802.11b channel 1 is within the ham band. This means that, as a ham, you can use this channel under FCC part 97 instead of unlicenced FCC part 15. In other words, as long as you broadcast your callsign every ten minutes (say as the contents of an ICMP packet or the essid), you can legally use up to 1 watt and drown out all neighbouring signals. Additionally, there's no question of the legality of using high gain directional antennae as long as don't exceed one watt peak output power.
I.. I think my head just popped. Well-played sir! I have to unwillingly congratulate you.
I agree, this is by far the best part of thALL GLORY TO THE HYPNOTOAD!
Sounds very similar to my laptop (Sharp Actius MM10, only link I could find is this review). It's super small, super light, good Linux support, and totally awesome for doing non CPU-intensive applications (like programming). It has the the same key layout with fn-left for home, which I've come to miss on almost every other keyboard I've ever used. I've also been spoiled with long battery life since I got the nine hour for this guy. Considering my current machine was last produced in 2003, it sounds like the sony may be a very reasonable machine to upgrade to.
That said, have you run into any downsides with it? Keep in mind I'm used to most of the limitations of a tiny laptop.
Normally I say don't feed the trolls, but hot damn, it's nice to hear someone with a pair of balls in the midst of all the political correctness bullshit we deal with daily. Good show, sir.
I suppose this could lead to a problem if one has a long running process holding onto descriptors for huge files, but you seem to imply that they'll be freed eventually anyway. Anyway I don't mean to troll, just have nothing better to do on a saturday morning than nitpick!
A sibling post mentions that the default non-sync behaviour can lead to the mv problem that the article boils down to. Perhaps you should make sure you mount your external media with sync just to be sure there won't be a problem.
~The Plauge
And by the way, that's just a euphemistic way of saying that you're the product.
You have to be a subscriber (yeah I shelled out the 5 dubloons). I won't do this too much more since it apparently taxes the DB, but here you go.
Happy birthday Slashdot. As promised, readers get the gifts. wiredog comment number 1 of 2181 ;).
If you're on a unix system, there are two very nice browsers that I know of:
Dillo runs on X and uses gtk 1.2 as a toolkit [oldschool]. It doesn't have a lot of features [hell, it doesn't even do CSS], but it's the leanest, fastest graphical browser I've ever used that integrates at all with other X applications.
Links2 runs in the terminal or [with the -g options] under X. The X version is ugly and doesn't integrate with other X apps, but it works incredibly well and even has support for some more advanced features like Javascript, which of course can be disabled if you like. I frequently run links2 on my laptop with limited memory and, while it may not be as pretty as Firefox, it definitely gets the job done more than 95% of the time.
DRM restricts usage. GPL3 restricts distrubution [and explicitly states that it does not apply to usage]. Therein lies the difference.
Not that I'm a GPL proponent by a long shot.
I suppose my understanding of OpenVPN must only be applicable to an older version in that case. I'll read into the source a bit more on that, but I do stand corrected.
The whole idea of needing to get the entire stream to decrypt it is absolutely correct. However, it depends on what you define as the ``whole stream''. In the case of SRTP, they define each UDP packet as an entire, distinct stream. In fact, SRTP does not define usage with any stream cypher. The only cypher it allows in the spec is AES [a block cypher] operating in special modes similar to CBC [output feedback or some strange variation on counter] with each packet representing a single stream.
SSL isn't any sort of cypher, it is a suite of crypto tools. The things people most often use it for are public key encryption [usually with RSA] and symmetric encryption. For the latter, an implementation may provide any number of block cyphers operating in various modes that effectively make them stream cyphers. For what it's worth, the only widely used strictly stream cypher is RC4 and I don't hear about it being used much outside of WEP/WPA (although SSL implementations do typically include it for completeness and backward compatibility).
Unless it's changed drastically recently, OpenVPN uses SSL to encrypt each UDP packet. It uses one of SSL's block cyphers in a streaming manner and treats each packet as a distinct stream. That way, it can be decrypted independently of other packets and injected into the tun/tap device on the remote end.
SRTP works in a similar manner, although you are correct in that it doesn't use SSL. Since UDP packets are meant to be semi-independent, both OpenVPN and SRTP have certain issues to handle, such as anti-replay measures and such, but both protocols define ways of handling this and are both quite secure in practise.
Skype probably using some timing measures to prevent the user from attaching a debugger, and ltrace may alter the timing enough so that Skype believes this is the case. If you're outputting the ltrace debugging to the terminal, that could very well be the case, because terminal output is pretty slow. Maybe outputting it using the -o flag would make it work. I don't use Skype, otherwise I'd try myself.
Apple does have the home turf advantage of having the source to OS 9. Not to mention, Apple isn't afraid of deprecating and even making old software obsolete. Versions of OS X running on Intel Macs do not have support for Classic applications, and most of their customers simply don't care. Microsoft is stuck supporting legacy code written for 16 bit versions of Windows right next to the latest and flashiest modern apps.
It's a different business model with a different customer base. Unfortunately, those who are on the sidelines trying to implement a mostly undocumented API are stuck with what they can reverse engineer. That leads to a project that is admittedly less polished than one where the source of the API being implemented is available.
So does GNOME. It's called GConf and it stores data hierarchically not too much unlike the Windows registry. Much like an LDAP server, the frontend has a unified API, but the backend can be any data store. The default is XML files in /etc/gconf, but nothing prevents you from storing it in a legit RDBMS. There are libraries for accessing it in most languages, as well.
Why didn't it catch on? Most [all?] GNOME projects use it now, and a handful of others do. I'm sure the Qt mirror-mirror version of GConf is much the same for KDE apps.
Why wouldn't I use it? Why bother with forcing the user to have another dependency when a dotfile is more than good enough for a standalone console app. In a more perfect world, where I could count on the user having GConf or Qt's version, maybe it'd be different. But for now, I'm afraid I have to stick to a simpler text file configuration for most things, which unfortunately means one parser per app.