I think what you're actually saying is that, in current implementations, file extensions might be a safer way of representing type metadata than hidden type & creator codes, and you might be right. But I think the important point that you miss is that file extensions can be spoofed too -- look at all the windows script viruses that had an extension like file.jpg.vbs, and people fell for it by the millions.
The problem here isn't metadata -- filetype is a metadata aspect that can be encoded in a variety of ways, including up front ones like extensions and more obscure ones like type codes, but that doesn't mean one or the other is "more" metadata-esque.
The best approach is not to get rid of it, but to come up with an interface that shows as much of it as possible -- or at least the core aspects like filetype information. Both the Mac Finder and the Windows Explorer can show this info by default when you browse by list view. The next step -- and it could be tricky to balance security against usability here -- would be to make it difficult to munge the associations derived from filetype data, so no easy to mask foo.gif.exe files, no maskable type or creator codes. I don't know what the best way to do this might be, though I think that the Unix magic number system is a pretty clever hack that could be useful here, if computationally expensive to implement (but then with modern hardware, who cares?).
And with Apple's proposed adoption of file extensions as the standard filetype recogntion scheme, they'll be in the same boat as all the others anyway. The more I think about it, the more I realized what an interesting area file metadata & it's repurcussions is.
Stong metadata allows applications like Signwave FinderMail to exist (individual emails are stored as individual files, and handled in the Mac Finder like any other files, in folders and sorted by date and so on), and it was what BeOS was pushing hard & well with their advanced filesystem, and Microsoft may be copying in supposed plans to make their next generation filesystem out of SQL Server, rather than NTFS.
It seems like file extensions suck as a way of managing all this, and I think all the major vendors & open source development groups realize this, but it's a lowest common denominator that we're having a hard time shaking off.
And that brings me to my point and my question. Does this problem affect only the Windows versions of IE, or is it a problem on the Macintosh too. What is the proposed fix to this? Clearly it seems to be an architectual problem, but will the solution also be architectual? Will MS accelerate any efforts to move away from file extensions? (I doubt it, but you can always hope...). Will this discourage Apple from adopting them while deprecating what they've used in the past? I'd like to see how big the fallout of this could be, particularly if an nasty exploit crops up & there's no easy fix. Hmm...
Well, he seems to know enough to know that he doesn't really care about Perl. He's a Lisp guy that's going for a Lisp job. Why would Perl's case sensitivity make a whiff of difference to him? Lay off already...
I think Bioinformatics is still too new of a field for there to be many books out there. O'Reilly has two books, but one is aimed at absolute newbies that are looking for the ON button, while the others is for people that have found the ON button and are trying to start out with Perl.
I'd also be interested in finding something a bit more advanced, but as of yet it doesn't seem to exist, and it seems like a perfect opportunity for someone to step in and write one. I'm an intermediate Perl monkey and I remember a bit of my last biology class back in high school, but that doesn't put me in a strong enough position to be trying to teach anything to anyone else yet. This doesn't sound like a problem for the original poster. Maybe he could spend the time waiting for this job by writing the first Lisp for Biologists book? I know I'd be interested in it...
Not really a direct reply to what you're saying, but this is also an interesting issue in coding (as opposed to finished software -- I just mean the code here).
<anectode>When I was a beginning computer science student, one of our assignments was to find an implementation of the insertion sort algorithm & reimplement it in C++. The only copy of it I could find was from a Venezuelan web site, so all the variables & functions were named in Spanish. This really confused me at first, trying to decipher both C++ and Spanish at the same time, but it made me realize that everything that I'm writing is "in" English, even if I'm writing English Perl or English C++ or whatever.
</anecdote>
A few weeks ago, I read an article that made pretty much the same point, but in reverse -- an American programmer was asking a Panamanian [sp?] programmer if it was annoying to have to look at more or less all reference material in American English. The reply was very interesting to me -- he basically replied by asking if you've ever read sheet music, and been annoyed by all the italian on there: allegro, sotto voce, con vivissimo, etc. Usually this is seen as charming, and just part of the learning experience when you learn to read music -- and not as any kind of cultural imperialism on the part of the Italians.
It seems like reading & writing software might be on track to be the same way. If for some reason people are still manually writing programs 500 years from now, they might be making software to run in whatever their vernacular is, but maybe the written code will itself use American English notation from the Digital Age, just as musicians today use Italian notation from the Renaissance.
I like that idea...:)
Even if the variables & functions/subs are in the vernacular, the builtins -- for, if, while and so on -- are in English, so the issue isn't really avoidable unless you're using a language that was designed from scratch to use some other [human] reference language. The only really non-American/English one I can think of at the moment is Ruby, and even though it's Japanese it still uses the English conventions. I think this is a sign of how deeply embedded this has become already, and we're only 50 years into the age of computers -- a digital renaissance:)
Still, that's just the term I'm aware of -- CJKV, referring to those four languages. I'm assuming that it's because those accent marks are used so heavily that it might as well be a different alphabet, albeit one that looks a lot like the Latin alphabet. Something like how the Slavic [Russian etc] alphabet is an evolutionary descendant of Greek & Latin, Greek grew out of Phoenician [? I think that was the ancestor alphabet...?], etc.
But hey, don't take my word for it, check out the obligatory O'Reilly book...:)
Why should Java be the only internationalizable -- ugh, that's too long -- the only I10N-able language? If you put in a bit of forethought -- abstract all your strings out into language specific resource files / db entries / whatever, ditto for images -- then a basic level of I10N should be and in fact is achievable in any programming language.
The tricky part has nothing to do with coding language preference, but in the overall design of the application itself. Provided that you can come up with acceptable translations of all your output strings -- which itself can be tricky -- that still doesn't really address more subtle interface issues you might face, depending on what you're trying to do.
For web design, it could be worthwhile to have drastically different versions of your content for different locales -- IKEA and the BBC are interesting case studies for this. For other applications, one interface framework might be fine, but really this involves a lot of work and study of your target audience, and it goes far beyond (and is much more interesting than) the question of what language you code in.
That said, Unicode is a truly terrifying thing, and any language that makes it easier to work with is a welcome thing. Java supposedly uses Unicode internally, and if that helps as much as it seems like it should then great. Otherwise, or maybe even still, you face a much gentler slope in going to other Latinish languages (most of the European ones and any of the others that have adopted that alphabet or at least have a cultural standard for & acceptance of it (thus Japanese counts, Chinese doesn't), to anything with a much different character set (Russian, Arabic, Hebrew) and beyond (the CJKV languages -- Chinese, Japanese, Korean, Vietnamese).
I can deal with the prospect of planning for French, German, Spanish, and Italian versions of work that I do, but having to go beyond that is a very daunting prospect. And, of course, and interesting one...:)
The feds have been accused of this before, though it's unclear to me whether or not the accusations are valid. Still, this would be a great way to deliver the application, and, as another commenter astutely noted, it would get the justice department to look at the convicted monopolists a bit less negatively.
Certainly, it wouldn't the first time that the US government had aligned themselves with nastypeople...
Truly your delusions know no end. You're breathing the stench around here just a little bit too deeply. Yes, Linux has a reasonably secure architecture, more so than the other consumer OSes. No, that doesn't mean it's perfect. I repeat: No, that does not make it perfect. You seem to be having trouble with that idea, but I assure it's true.
You look at the diverse landscape of libraries, programs, and kernel versions and yell huzzah, what a wonderful defense against viruses. I look at the same thing and realize why it's such a pain in the ass to get *anything* to work without having to go through no end of pain & humiliation. Sure, it's rough for the virus guys -- at least the ones too crude to wrap that "./configure && make && install" inside an otherwise benign package such as an RPM -- but more importantly it's also a pain in the ass for the thousands of non-malicious users out there. You're right, I don't know if Linux will ever get to any kind of stable, standardized plateau. Maybe it won't, but unlike you I'd find that a real shame.
Most people don't sit down in front of a computer hoping to be some sort of technological pioneer, they just want to use the damn thing & get on with their lives. You could argue that the Linux system is more powerful than Windows, and I'd agree, but again most people couldn't give a damn. They just want it to work, easily and effectively. If Linux is ever to become a major consumer OS -- and there are about a billion little green men with blue underwear that are betting that it will someday -- then these issues are going to need to be addressed. You can preach all you want from your plastic tower, but you just look like an oaf from down here...
Yeah. Sure. Just make sure you leave enough of whatever it is you're smoking in that pipe so that we can all get as addled as you are on this one.
Mac OSX is becoming an interesting case study in Unix For The Masses. Default Linux is, as the Register recently noted, [from memory, can't find a link] "a paragon of Stalinistic control freakery", and that has made it more secure out of the box than the average WinME box, but more importantly it has also scared off millions, and rightly so. Apple's engineers knew well that if they wanted to bring this architecture to the masses -- the way the Gnome & KDE folks do -- then they'd have to encapsulate & hide as much of that control freakery as possible.
And for the most part they've done a good job, but there have been some serious glitches, like programs that would launch themselves as root, or a broken iTunes installer that wiped out whole disk partitions because of one mistyped "rm" command in an installer script. Pay attention, you seething Linux hordes, because if you want to hit the big time then this is your future. You too will face these problems as the system matures & seeks out a wider audience.
The only "secure" system is either (pick your punch line) the one that hasn't been built yet, or the one you bought a decade ago and still haven't plugged in yet. All of the others -- all of them -- have problems of one kind or another, and all of them always well. Welcome to real life, kids.
...until of course the first big cross platform or Linux only virus comes along and trashes your computer[s], which we all know is just a matter of time.
Your OS is certainly more esoteric, but it has holes like all the rest of them do. Your immunity thus far isn't an indication that there are no holes -- there are always holes -- but that the *nix enviroment hasn't yet been able to cultivate & propagate any really serious viruses yet.
One of two thing is likely to happen: Linux's popularity will crest & wane, and people will stop using it (unlikely, I hope:), or it will continue to get more popular, and as it does so it will provide an ever more appealing target for virus writers, licking their chops at all the complacency out there....
That's a good point, and it widens up the scope of this a bit. For example, in my case I was working for a medical company a few years ago doing video imaging stuff of, well, open wounds. ("Open sores", actually, though the software was proprietary nyuk nyuk nyuk...) (and no I'm not kidding -- I really did look at pictures of open sores all day...).
When I talked to recruiters, it was strongly suggested that I write my resume in such a way that the gory parts about the job were downplayed while the technical aspects that I wanted to expand upon in future jobs were highlighted. I even referred to that employer by their initials rather than the full name (which has "Wound" in it), just to cut down on the uncomfortable interview questions (for the interviewer, not really to me).
But now, I'm starting to find bioinformatics interesting, so I'm doing the opposite with recent versions of the resume. I don't hide the nature of that job or the name of the company, and I make it clear that I am comfortable working in a medical environment. It's already landed me one job, albeit a temp one, and I'm hoping I can go further with it.
The point is, having an uncomfortable spot on your resume can be both good & bad, depending on where you want to go and who you want to work for. As one commenter noted, having pornsite experience isn't at all a bad thing if you want to keep working for pornsites -- they are profitable after all. And if you don't want that sort of job in the future, then just downplay it.
Either way, the idea is the same: have an idea of what sort of work you want to find and what sort of work enviroment you'd like to be in, and then draft your resume in such a way that you draw attention to the areas that such a job would find as strengths. No "black mark" is fundamentally a problem if you can use it to your advantage somehow.
No need to prowl the flea markets just yet -- the comics seem to be in perpetual reprint mode, and have been for most of the 90s.
If you're lucky enough to live in the Boston area, you can walk right into a New England Comics store and they'll have piles of copies, or you can try Newbury Comics (which is more of a music store than a comic store, in spite of the name) which usually has copies of Tick available.
Otherwise, any comic book shop should either have it or be able to get it, or you can of course try Amazon
or New England Comics site.
You want to get issues 1-12, either individually (current editions are a couple bucks a piece, older prints can rise quickly) or as anthologies (two of them, probably $25 or so for current editions of both). Later issues and the various spinoffs & colorized versions were generally inferior to the original series, so save them for later if you really get into the first ones.
The main exceptions to that rule of thumb are "Paul the Samurai", which was also written by Ben Edlund (at least the first issue or two -- don't remember if it went anywhere after that) and "Chainsaw Vigilante", which I think was by someone else but was still pretty funny (as a parody of Batman / Punisher type violent dark knight comics). Otherwise, stick to the originals, they're still the best...
I'm slightly disappointed that my comment didn't make it (first time I'd ever had a top rated interview question, but oh well...:).
I am, however, very disappointed that "CleverNickName"'s other question didn't get through! Never have I seen a better (in a good way) case of karma whoring / desperate plea for work...:)
Come on Ben, if you're reading this, what about that question of his? Can he get the job?
Would it make sense then to have both CVS & VSS working in parallel, with CVS managing the textual stuff (code, text docs, etc -- any chance the word DOCs could be resaved as RTF? doubt it...:) and VSS doing the binaries?
My last job was a VSS shop, but I didn't deal with it very much. Everyone else was doing local machine development, while I was the web guy, so I could get away with not keeping all my code in VSS like the others. Still, I can see what people are saying about VSS being more peer-to-peer than client-server.
With that in mind, could CVS be set up to act as a peer to VSS, or VSS as a client to CVS? The latter makes a little more sense to me, but might not be implementable as long as VSS remains closed source. Getting CVS to feed binary data over to VSS might not be as clean a solution, but it seems like it should be doable.
That is, provided that you feel it makes sense to keep both systems running in parallel. I'm not familiar enough with their similarities & differences to say for sure...
I disagree. The ugly truth about open source is that, in spite of the grassroots image, every significant project has been primarily driven in a top down way. Think about the irony there. When you think closed source, you think Windows, Oracle, Photoshop, etc., all of which have big corporate names behind them, and thus their unseen legions of developers -- Microsoft, Oracle, Adobe. When you think open source you think Linux, Perl, Emacs, and most of them have the names of individuals associated with them -- Torvalds, Wall, Stallman.
This first guy said outright that a lot of people have downloaded his application but few have submitted patches back to it. That flatly contradicts your suggestion. And as for the second guy, he doesn't sound so different -- he still seems to want to run things, he just wants a break from the tedium of actually writing the code. Boo frickin hoo to him, I say -- if this Java game is his baby he shouldn't expect someone else to care about it as much as he did. It's much easier for me to sympathize with the CVS guy -- he's done what he set out to do, now he's willing to let others go where they will with it. If the project is to continue, this is what will have to happen: some other lead developer (or group of developers) will have to see something in the project that they want fleshed out, so it can become *their* itch to scratch, not someone elses. People don't tend to scratch other peoples' software itch unless they're being paid to do it, which brings us back towards the proprietary model.
What you say sounds nice in theory and adheres nicely to the party line, but the sad fact is that the mechanics of things don't let them work out that way. Only the biggest projects have anything looking like a team effort -- Perl6 comes to mind -- and even then they're being lead by a core group of people, so it isn't really an exception to the rule.
The iPod is a pretty cool little device, but it would be even cooler if it could record sounds on the go. That way, it could be a replacement for those microcasette voice recorders that a lot of people use, or you could just (assuming an input jack, rather than a little built in microphone) plug it into the headphone jack of a soundboard or walkman or whatever. You get the idea.
Don't just think music here: consider that, if paired with moderately decent voice recognition software back on the desktop computer, you could have close to instant transcription of speeches, lectures, meetings, etc. This is really what the PDA was invented to do, but you have to teach yourself how to get data in & out of the device, and even with experience it's a slow process.
Something like the iPod could solve the same problem in a completely novel way. It has more than enough storage capacity to record a lot of audio data, and might [???] have the processing power to do so easily. [If it doesn't have the horsepower, then maybe iPod2 can bulk up on cpu & ram, along with that built-in mic.] No futzing around with graffiti -- just leave it on your desk, recording passively. Later on, it can be rapidly synced with the much more powerful Mac/PC/whatever, where you can do the interesting heavy duty processing on your data -- transcribe it, upload it, burn to cd, whatever. Brilliant.
Having audio out -- where you can record stuff (songs, etc) on your computer & carry it with you on the go -- is cool. Having audio in -- where you can bring sounds from out in the world back to the computer for processing -- would be even better. I want to see someone build such a device.
Actually, according to the preface, it was the publisher that was squeamish about it. He still thought it was clever, but conceded that maybe it was too clever by half, so allowed them to change the title...
Long key length doesn't mean hard to break. Overly complex encryption schemes doesn't mean hard to break. I'm sure these people are very smart, and I wouldn't pretend to have a clue how to break them myself, but the fact is that it's silly to say that any encryption strategy is strong just because it's impressively arcane. The fact is that for regular personal & commercial use, ciphers of as little as 128 bits are perfectly safe and will remain so for a good while -- distributed cracking efforts don't really invalidate them as much as they prove how difficult they are to break, and they have proven that they are in fact comfortably difficult to break. I'm sure the NSA wants a higher level of comfort, and I'm sure they have a lot of smart people that spend all their time trying to do even better, but I'm also sure that anything that is cryptographically secret or proprietary is also cryptographically unproven. That might be okay -- the NSA might not be too worried about formal academic proofs for all I know -- but in the absence of better knowledge and analysis, it's really impossible to comment on the quality of what they're using.
Well yes, but that's not the security model here. The idea is to have a strong perimeter, for the same sorts of reasons you'd use a firewall. Within that perimeter you [generally, not you specifically] can use the same software & hardware that is used out on the public internet, hopefully secure in the belief that any malware from the outside can't get in, and anything sensitive on the inside can't get out. The problem is, you're focusing too much on that perimeter defence, and getting lulled into thinking that the interior doesn't matter. You can't do that. In the case Schneier cites, one or more people took laptops to & from work, getting infected at home and then plugging the computer into the 'secure' network in the office, and whoops now it's past your defences.
I just can't parse the beginning of your second sentence. There is...what, exactly? Hardware encryption with more hardware encryption? I don't know what that's supposed to mean...
Anyway, if you see a very tall fence that goes part of the way around the building, do you try to go over the fence, or do you try the gate? Hacking into this network from home may well be an exercise in futility, but that isn't to say that it'll be safe from malicious or incompetent insiders.
And key length really doesn't mean very much. A long key with a bad encoding algorithm is no better than a short key with a good algorithm, or put another way, if that 1024 key chain runs an algorithm that can only generate 32 bits of entropy, then you might as well just use a 32 bit key. Furthermore, keys of the same length aren't necessarily of equal quality. A clever algorithm might be able to get more use out of say 40 bits than a less clever algorithm does in 64, but then that's just the earlier idea expressed in reverse.
In any event, the main point is that key length looks good in marketing literature, but the best way to know for sure is to have a cryptographically established algorithm, and the more open that algorithm is the better you can trust that it's actually secure. Don't be impressed just because someone told you an algoritm can spit out lots of bits, since anyone can do that:
for (1..10000) { print $_; }
Hey look at that I just came up with a ten thousand key algorithm, I'm smarter than the NSA! Yeah right...:)
And I'm saying, and Bruce Schneier is saying, for that matter George Bush is saying that we're not talking about four computers and a hub. We're talking about a relatively large network of computers, pretty much all of which are likely to have floppy drives, network cards, modems, and various connector ports. You might be able to guarantee that the hardware is minimally secure -- take out the modem, ban use of the floppy drive, etc -- but I can absolutely guarantee that you can't get the users to be 100% vigilant about never transferring data to & from the open public internet, and that only has to happen once to violate the integrity of this so called isolated network. Your reduction to absurdity is, as advertised, absurd.
Slashdot Mirror
So what if the Navy denies that it's true, I still think it's hilarious... :)
The problem here isn't metadata -- filetype is a metadata aspect that can be encoded in a variety of ways, including up front ones like extensions and more obscure ones like type codes, but that doesn't mean one or the other is "more" metadata-esque.
The best approach is not to get rid of it, but to come up with an interface that shows as much of it as possible -- or at least the core aspects like filetype information. Both the Mac Finder and the Windows Explorer can show this info by default when you browse by list view. The next step -- and it could be tricky to balance security against usability here -- would be to make it difficult to munge the associations derived from filetype data, so no easy to mask foo.gif.exe files, no maskable type or creator codes. I don't know what the best way to do this might be, though I think that the Unix magic number system is a pretty clever hack that could be useful here, if computationally expensive to implement (but then with modern hardware, who cares?).
Stong metadata allows applications like Signwave FinderMail to exist (individual emails are stored as individual files, and handled in the Mac Finder like any other files, in folders and sorted by date and so on), and it was what BeOS was pushing hard & well with their advanced filesystem, and Microsoft may be copying in supposed plans to make their next generation filesystem out of SQL Server, rather than NTFS.
It seems like file extensions suck as a way of managing all this, and I think all the major vendors & open source development groups realize this, but it's a lowest common denominator that we're having a hard time shaking off.
And that brings me to my point and my question. Does this problem affect only the Windows versions of IE, or is it a problem on the Macintosh too. What is the proposed fix to this? Clearly it seems to be an architectual problem, but will the solution also be architectual? Will MS accelerate any efforts to move away from file extensions? (I doubt it, but you can always hope...). Will this discourage Apple from adopting them while deprecating what they've used in the past? I'd like to see how big the fallout of this could be, particularly if an nasty exploit crops up & there's no easy fix. Hmm...
I think Bioinformatics is still too new of a field for there to be many books out there. O'Reilly has two books, but one is aimed at absolute newbies that are looking for the ON button, while the others is for people that have found the ON button and are trying to start out with Perl.
I'd also be interested in finding something a bit more advanced, but as of yet it doesn't seem to exist, and it seems like a perfect opportunity for someone to step in and write one. I'm an intermediate Perl monkey and I remember a bit of my last biology class back in high school, but that doesn't put me in a strong enough position to be trying to teach anything to anyone else yet. This doesn't sound like a problem for the original poster. Maybe he could spend the time waiting for this job by writing the first Lisp for Biologists book? I know I'd be interested in it...
please let me know
'cause if it's not a scooter
you'd better just say so...
</huey lewis ripoff>
sorry, made me giggle... :)
Uhh, anyone around here work for Deka? They're long-commute distance from here, and seem like a cool place to work for. Must send an resume...
<anectode>When I was a beginning computer science student, one of our assignments was to find an implementation of the insertion sort algorithm & reimplement it in C++. The only copy of it I could find was from a Venezuelan web site, so all the variables & functions were named in Spanish. This really confused me at first, trying to decipher both C++ and Spanish at the same time, but it made me realize that everything that I'm writing is "in" English, even if I'm writing English Perl or English C++ or whatever. </anecdote>
A few weeks ago, I read an article that made pretty much the same point, but in reverse -- an American programmer was asking a Panamanian [sp?] programmer if it was annoying to have to look at more or less all reference material in American English. The reply was very interesting to me -- he basically replied by asking if you've ever read sheet music, and been annoyed by all the italian on there: allegro, sotto voce, con vivissimo, etc. Usually this is seen as charming, and just part of the learning experience when you learn to read music -- and not as any kind of cultural imperialism on the part of the Italians.
It seems like reading & writing software might be on track to be the same way. If for some reason people are still manually writing programs 500 years from now, they might be making software to run in whatever their vernacular is, but maybe the written code will itself use American English notation from the Digital Age, just as musicians today use Italian notation from the Renaissance. I like that idea... :)
Even if the variables & functions/subs are in the vernacular, the builtins -- for, if, while and so on -- are in English, so the issue isn't really avoidable unless you're using a language that was designed from scratch to use some other [human] reference language. The only really non-American/English one I can think of at the moment is Ruby, and even though it's Japanese it still uses the English conventions. I think this is a sign of how deeply embedded this has become already, and we're only 50 years into the age of computers -- a digital renaissance :)
Still, that's just the term I'm aware of -- CJKV, referring to those four languages. I'm assuming that it's because those accent marks are used so heavily that it might as well be a different alphabet, albeit one that looks a lot like the Latin alphabet. Something like how the Slavic [Russian etc] alphabet is an evolutionary descendant of Greek & Latin, Greek grew out of Phoenician [? I think that was the ancestor alphabet...?], etc.
But hey, don't take my word for it, check out the obligatory O'Reilly book... :)
The tricky part has nothing to do with coding language preference, but in the overall design of the application itself. Provided that you can come up with acceptable translations of all your output strings -- which itself can be tricky -- that still doesn't really address more subtle interface issues you might face, depending on what you're trying to do.
For web design, it could be worthwhile to have drastically different versions of your content for different locales -- IKEA and the BBC are interesting case studies for this. For other applications, one interface framework might be fine, but really this involves a lot of work and study of your target audience, and it goes far beyond (and is much more interesting than) the question of what language you code in.
That said, Unicode is a truly terrifying thing, and any language that makes it easier to work with is a welcome thing. Java supposedly uses Unicode internally, and if that helps as much as it seems like it should then great. Otherwise, or maybe even still, you face a much gentler slope in going to other Latinish languages (most of the European ones and any of the others that have adopted that alphabet or at least have a cultural standard for & acceptance of it (thus Japanese counts, Chinese doesn't), to anything with a much different character set (Russian, Arabic, Hebrew) and beyond (the CJKV languages -- Chinese, Japanese, Korean, Vietnamese).
I can deal with the prospect of planning for French, German, Spanish, and Italian versions of work that I do, but having to go beyond that is a very daunting prospect. And, of course, and interesting one... :)
The feds have been accused of this before, though it's unclear to me whether or not the accusations are valid. Still, this would be a great way to deliver the application, and, as another commenter astutely noted, it would get the justice department to look at the convicted monopolists a bit less negatively.
Certainly, it wouldn't the first time that the US government had aligned themselves with nasty people...
You look at the diverse landscape of libraries, programs, and kernel versions and yell huzzah, what a wonderful defense against viruses. I look at the same thing and realize why it's such a pain in the ass to get *anything* to work without having to go through no end of pain & humiliation. Sure, it's rough for the virus guys -- at least the ones too crude to wrap that "./configure && make && install" inside an otherwise benign package such as an RPM -- but more importantly it's also a pain in the ass for the thousands of non-malicious users out there. You're right, I don't know if Linux will ever get to any kind of stable, standardized plateau. Maybe it won't, but unlike you I'd find that a real shame.
Most people don't sit down in front of a computer hoping to be some sort of technological pioneer, they just want to use the damn thing & get on with their lives. You could argue that the Linux system is more powerful than Windows, and I'd agree, but again most people couldn't give a damn. They just want it to work, easily and effectively. If Linux is ever to become a major consumer OS -- and there are about a billion little green men with blue underwear that are betting that it will someday -- then these issues are going to need to be addressed. You can preach all you want from your plastic tower, but you just look like an oaf from down here...
Mac OSX is becoming an interesting case study in Unix For The Masses. Default Linux is, as the Register recently noted, [from memory, can't find a link] "a paragon of Stalinistic control freakery", and that has made it more secure out of the box than the average WinME box, but more importantly it has also scared off millions, and rightly so. Apple's engineers knew well that if they wanted to bring this architecture to the masses -- the way the Gnome & KDE folks do -- then they'd have to encapsulate & hide as much of that control freakery as possible.
And for the most part they've done a good job, but there have been some serious glitches, like programs that would launch themselves as root, or a broken iTunes installer that wiped out whole disk partitions because of one mistyped "rm" command in an installer script. Pay attention, you seething Linux hordes, because if you want to hit the big time then this is your future. You too will face these problems as the system matures & seeks out a wider audience.
The only "secure" system is either (pick your punch line) the one that hasn't been built yet, or the one you bought a decade ago and still haven't plugged in yet. All of the others -- all of them -- have problems of one kind or another, and all of them always well. Welcome to real life, kids.
Your OS is certainly more esoteric, but it has holes like all the rest of them do. Your immunity thus far isn't an indication that there are no holes -- there are always holes -- but that the *nix enviroment hasn't yet been able to cultivate & propagate any really serious viruses yet.
One of two thing is likely to happen: Linux's popularity will crest & wane, and people will stop using it (unlikely, I hope :), or it will continue to get more popular, and as it does so it will provide an ever more appealing target for virus writers, licking their chops at all the complacency out there....
Yes but Vim ~ Emacs :). :)
(I guess tilde would be the ascii equivalent of "is approximately equal to"...
When I talked to recruiters, it was strongly suggested that I write my resume in such a way that the gory parts about the job were downplayed while the technical aspects that I wanted to expand upon in future jobs were highlighted. I even referred to that employer by their initials rather than the full name (which has "Wound" in it), just to cut down on the uncomfortable interview questions (for the interviewer, not really to me).
But now, I'm starting to find bioinformatics interesting, so I'm doing the opposite with recent versions of the resume. I don't hide the nature of that job or the name of the company, and I make it clear that I am comfortable working in a medical environment. It's already landed me one job, albeit a temp one, and I'm hoping I can go further with it.
The point is, having an uncomfortable spot on your resume can be both good & bad, depending on where you want to go and who you want to work for. As one commenter noted, having pornsite experience isn't at all a bad thing if you want to keep working for pornsites -- they are profitable after all. And if you don't want that sort of job in the future, then just downplay it.
Either way, the idea is the same: have an idea of what sort of work you want to find and what sort of work enviroment you'd like to be in, and then draft your resume in such a way that you draw attention to the areas that such a job would find as strengths. No "black mark" is fundamentally a problem if you can use it to your advantage somehow.
If you're lucky enough to live in the Boston area, you can walk right into a New England Comics store and they'll have piles of copies, or you can try Newbury Comics (which is more of a music store than a comic store, in spite of the name) which usually has copies of Tick available.
Otherwise, any comic book shop should either have it or be able to get it, or you can of course try Amazon or New England Comics site.
You want to get issues 1-12, either individually (current editions are a couple bucks a piece, older prints can rise quickly) or as anthologies (two of them, probably $25 or so for current editions of both). Later issues and the various spinoffs & colorized versions were generally inferior to the original series, so save them for later if you really get into the first ones.
The main exceptions to that rule of thumb are "Paul the Samurai", which was also written by Ben Edlund (at least the first issue or two -- don't remember if it went anywhere after that) and "Chainsaw Vigilante", which I think was by someone else but was still pretty funny (as a parody of Batman / Punisher type violent dark knight comics). Otherwise, stick to the originals, they're still the best...
I am, however, very disappointed that "CleverNickName"'s other question didn't get through! Never have I seen a better (in a good way) case of karma whoring / desperate plea for work... :)
Come on Ben, if you're reading this, what about that question of his? Can he get the job?
My last job was a VSS shop, but I didn't deal with it very much. Everyone else was doing local machine development, while I was the web guy, so I could get away with not keeping all my code in VSS like the others. Still, I can see what people are saying about VSS being more peer-to-peer than client-server.
With that in mind, could CVS be set up to act as a peer to VSS, or VSS as a client to CVS? The latter makes a little more sense to me, but might not be implementable as long as VSS remains closed source. Getting CVS to feed binary data over to VSS might not be as clean a solution, but it seems like it should be doable.
That is, provided that you feel it makes sense to keep both systems running in parallel. I'm not familiar enough with their similarities & differences to say for sure...
This first guy said outright that a lot of people have downloaded his application but few have submitted patches back to it. That flatly contradicts your suggestion. And as for the second guy, he doesn't sound so different -- he still seems to want to run things, he just wants a break from the tedium of actually writing the code. Boo frickin hoo to him, I say -- if this Java game is his baby he shouldn't expect someone else to care about it as much as he did. It's much easier for me to sympathize with the CVS guy -- he's done what he set out to do, now he's willing to let others go where they will with it. If the project is to continue, this is what will have to happen: some other lead developer (or group of developers) will have to see something in the project that they want fleshed out, so it can become *their* itch to scratch, not someone elses. People don't tend to scratch other peoples' software itch unless they're being paid to do it, which brings us back towards the proprietary model.
What you say sounds nice in theory and adheres nicely to the party line, but the sad fact is that the mechanics of things don't let them work out that way. Only the biggest projects have anything looking like a team effort -- Perl6 comes to mind -- and even then they're being lead by a core group of people, so it isn't really an exception to the rule.
The iPod is a pretty cool little device, but it would be even cooler if it could record sounds on the go. That way, it could be a replacement for those microcasette voice recorders that a lot of people use, or you could just (assuming an input jack, rather than a little built in microphone) plug it into the headphone jack of a soundboard or walkman or whatever. You get the idea.
Don't just think music here: consider that, if paired with moderately decent voice recognition software back on the desktop computer, you could have close to instant transcription of speeches, lectures, meetings, etc. This is really what the PDA was invented to do, but you have to teach yourself how to get data in & out of the device, and even with experience it's a slow process.
Something like the iPod could solve the same problem in a completely novel way. It has more than enough storage capacity to record a lot of audio data, and might [???] have the processing power to do so easily. [If it doesn't have the horsepower, then maybe iPod2 can bulk up on cpu & ram, along with that built-in mic.] No futzing around with graffiti -- just leave it on your desk, recording passively. Later on, it can be rapidly synced with the much more powerful Mac/PC/whatever, where you can do the interesting heavy duty processing on your data -- transcribe it, upload it, burn to cd, whatever. Brilliant.
Having audio out -- where you can record stuff (songs, etc) on your computer & carry it with you on the go -- is cool. Having audio in -- where you can bring sounds from out in the world back to the computer for processing -- would be even better. I want to see someone build such a device.
I'm a loner, Dottie. A rebel. You wouldn't understand...
Actually, according to the preface, it was the publisher that was squeamish about it. He still thought it was clever, but conceded that maybe it was too clever by half, so allowed them to change the title...
Long key length doesn't mean hard to break. Overly complex encryption schemes doesn't mean hard to break. I'm sure these people are very smart, and I wouldn't pretend to have a clue how to break them myself, but the fact is that it's silly to say that any encryption strategy is strong just because it's impressively arcane. The fact is that for regular personal & commercial use, ciphers of as little as 128 bits are perfectly safe and will remain so for a good while -- distributed cracking efforts don't really invalidate them as much as they prove how difficult they are to break, and they have proven that they are in fact comfortably difficult to break. I'm sure the NSA wants a higher level of comfort, and I'm sure they have a lot of smart people that spend all their time trying to do even better, but I'm also sure that anything that is cryptographically secret or proprietary is also cryptographically unproven. That might be okay -- the NSA might not be too worried about formal academic proofs for all I know -- but in the absence of better knowledge and analysis, it's really impossible to comment on the quality of what they're using.
Well yes, but that's not the security model here. The idea is to have a strong perimeter, for the same sorts of reasons you'd use a firewall. Within that perimeter you [generally, not you specifically] can use the same software & hardware that is used out on the public internet, hopefully secure in the belief that any malware from the outside can't get in, and anything sensitive on the inside can't get out. The problem is, you're focusing too much on that perimeter defence, and getting lulled into thinking that the interior doesn't matter. You can't do that. In the case Schneier cites, one or more people took laptops to & from work, getting infected at home and then plugging the computer into the 'secure' network in the office, and whoops now it's past your defences.
Anyway, if you see a very tall fence that goes part of the way around the building, do you try to go over the fence, or do you try the gate? Hacking into this network from home may well be an exercise in futility, but that isn't to say that it'll be safe from malicious or incompetent insiders.
And key length really doesn't mean very much. A long key with a bad encoding algorithm is no better than a short key with a good algorithm, or put another way, if that 1024 key chain runs an algorithm that can only generate 32 bits of entropy, then you might as well just use a 32 bit key. Furthermore, keys of the same length aren't necessarily of equal quality. A clever algorithm might be able to get more use out of say 40 bits than a less clever algorithm does in 64, but then that's just the earlier idea expressed in reverse.
In any event, the main point is that key length looks good in marketing literature, but the best way to know for sure is to have a cryptographically established algorithm, and the more open that algorithm is the better you can trust that it's actually secure. Don't be impressed just because someone told you an algoritm can spit out lots of bits, since anyone can do that:
Hey look at that I just came up with a ten thousand key algorithm, I'm smarter than the NSA! Yeah right... :)
And I'm saying, and Bruce Schneier is saying, for that matter George Bush is saying that we're not talking about four computers and a hub. We're talking about a relatively large network of computers, pretty much all of which are likely to have floppy drives, network cards, modems, and various connector ports. You might be able to guarantee that the hardware is minimally secure -- take out the modem, ban use of the floppy drive, etc -- but I can absolutely guarantee that you can't get the users to be 100% vigilant about never transferring data to & from the open public internet, and that only has to happen once to violate the integrity of this so called isolated network. Your reduction to absurdity is, as advertised, absurd.