I think almost everyone involved agreed (and still agrees) that it would be cool for NetBeans and Eclipse to share a plug-in architecture, and even underlying framework code. It would allow a great leap in pooling OSS development resources, and would be a boon for plug-in developers, which in turn would help to make Java with *free* tools a better platform than competing MS technologies.
I wrote a version control plugin for JBuilder -- yet another IDE with its own plugin architecture -- and I'm currently learning the Eclipse plugin architecture so I can port it... yes, it sure would be nice if I could just deploy it as is to other IDEs!
But... I suspect that the whole merging idea was mostly conceived by management types who got a rude awakening when they started talking to the tool developers and found out what kind of effort it would take to actually do it.
The work involved would be mind-boggling... and it's not the sort of thing that would draw open-source developers. It definitely scratches an itch to implement that feature you've been longing for in your IDE of choice (which is why it's often easy to get lots of contributors to a good IDE; look how quick the Eclipse community grew!). But I'll be damned if I'm going to reimplement the same thing two years later for free.
The next version of any tool after it's been ripped apart and reassembled is usually much worse than the last version, too. I remember when JBuilder first switched to a version written in Java (3.5)... it hurt to see how many important features were broken or removed. Sure, you understand that this will help in the long run, but you don't want to be around while it fights it way back to mature status.
So would Sun and IBM be willing to pay what it would really take to get there? It would have been nice, but I'm not surprised the answer was no.
Check out the picture -- he's just some regular kid. I was expecting a more... athletic type, I guess. You know, someone who has greate endurance from running cross-country all through high school, or something.
Nope -- he looks like a regular video-gaming kid, but with superhuman determination.
I hope those shoes were comfy. Probably not, though, after 37 hours.
No, the "rules" not there to help the webdesigner. They are a best practice to allow the USER of your site
I think your point was implied in the parent post. What exactly are you disagreeing with?
The rules are intended to help the webmaster, because the webmaster is building the website. These are rules to follow while building websites, right?
Yes, every website is built with a primary goal of serving users, as books are written for readers. The user has no direct use for these rules, though of course when the rules help the webmaster achieve his goals, the user benefits (as does the webmaster, who succeeds in bringing in more traffic/sales/etc.).
As your post and the parent post suggested, the important thing here is to understand how these rules can help you (as a webmaster) achieve your goal of building the most useful and accessible website possible. Once you understand what they offer and how what you do affects your users, you can bend the rules.
Actually, that makes me suspect that domain registrars must be pushing pretty hard for this.
Think about it -- a French site would have to register their domain w/ the accents AND the unaccented domain: one to be correct, and the other for the foreigners. An international Japanese company might need dozens of domains, because of the different ways their name is transliterated into various languages.
Hm. It seems like there are going to be a lot of problems that this change can cause, mostly because it's NOT easy to type the chars that will be in some of these URLs. It's not obvious at all how to type an accented e (plus it's different by OS). Why? It's a cause of frustration even for English-only speakers! "So... you will resume sending me your what??" When I was studying French in school, I used to mark all the accents by hand into papers I typed up, after printing them out. It was just so much faster than any other method I found. I can't even imagine how I'd manage to input a URL in cyrillic or pictographs.
The thing is, though... this is the lesser of two evils. I really don't see everyone sharing a common language anytime soon, which would be the other solution. The internet all over the world is swiftly moving from academics and geeks to businesses to common folks, all over the world. Don't you WANT to be able to fully translate your website, so any bumpkin in Siberia can order your products? They aren't all going to learn a new alphabet.
Think about it. Just about every language has its own keyboard layout. All my emails from Europe looked pretty funny until I figured out how to change the keyboard layout... (yes, you can do this in many web cafes. Damn! I can't spell caf-ay without an accent!). Someone somewhere is going to have a tough time typing any given characters.
It's only fair if accessing foreign language sites is an equal pain-in-the-ass for all. The internet is not destined to be a single language medium.
Maybe the operating systems and keyboards need to improve. What a shocking thought that is. Hey, it would be a huge help to lots of frustrated kids trying to do their foreign language homework on a computer.
And really, if you think about it, how many foreign-language URLs do you type in during your day? Sometimes you get a search result that looks interesting so you translate it. Okay... you don't type that URL, you copy it and paste in the translator. Where else do we get URLs? When won't you be able to just copy it? Very rarely...
Backups will contain the drafts in the future. Some them will surely survive.
There's a weird kind of paradox involved in what will survive, though.
Digital media has that wonderful property that it can be reproduced *perfectly* -- such that the copy is indistinguishable from the original -- but it must be copied or it will die.
You can burn your vacation videos to CD so your grandkids will be able to see them -- but that CD won't be readable anymore in a decade, never mind a century. If you faithfully make sure they're recopied every once in a while, though (and possibly converted to whatever new video formats are invented), your descendants 500 years hence will be able to see you waving from behind that sandcastle in California, as if it were filmed yesterday. No more flipping through yellowed photographs or crumbling newspaper clippings.... Imagine it! A scientist may use your video to prove his point about how the sunsets on the west coast have improved since California sank into the ocean.
He has to use family videos, though, because two decades of scientifically-recorded data on weather patters was all wiped out when a massive electromagnetic bomb was set up by terrorists in 2012.
Yeah, far-fetched example. I don't want to force the point, and definitely lots of stuff will survive... but our progeny won't be making the same kinds of attic discoveries that we can today.
"Hey, viddy all these ancient discs that Old Grampy Limp Devil had cached away up here! Can you run them? Nothing, huh? Oh, well."
I read an interesting article a few years ago about how even our hard copy (books, magazines, musical scores, etc.) won't be nearly as useful to future historians.
Why?
Current historians learn a lot about each writers creative process, and how writers evolved their ideas, from drafts and corrections. Music scholars pore over every scratched-out note, every furious scribbled comment, in Beethoven's draft scores. Writing music was laborious and hugely frustrating for Beethoven, unlike Mozart, who hardly stopped to think and made few if any corrections.
Future scholars won't know any of this stuff, looking back at our work. We use software to edit our work... so when we fix our errors they are gone forever. We change our minds and the original idea disappears in a puff of electrons. An electronic score of a Beethoven symphony only differs from a Mozart concerto in the musical style -- all of the other data is gone.
It's a sobering thought. Where else are we going to get this data? Not letters, because we write emails now, and regularly delete them (intentionally or not). Diaries? Some people still keep them on paper... but many store them on computer, or publish them in blogs (which as discussed will mostly be gone).
Sobering thought isn't it? It's not neccessarily hubris to say we ought to be saving more of this stuff; people a few hundred years from now should be able to learn from our failures, as well as our successes.
I noticed that too... this system seems closer to the role of the Sun in the Icarus story. Icarus' high-tech daddy built him some powerful wings (P2P tools?) that let him fly... but young foolish Icarus got cocky with his new power and flaunted it, challenging the "Gods" -- he flew too high, and got smoked by the Sun. Wings disintegrating, he plummeted from the sky into the unforgiving sea (of lawsuits?). Sploosh.
I wonder what kind of hardware they run the thing on? I'd laugh if were SUN.
Hey, now; be nice. I thought I talked about this somewhere, but here's more detail.
You're right that session cookies are a security hole, but it's much harder to use them, because most of the time when you steal them they're useless. Sessions expire, or are closed on log-out.
If you do your banking online, do you log out? Do you close the browser? Or do you even wait 15 minutes before browing to the shadier parts of the internet? Any of those and you're safe.
Here's what would have to happen for your banking session to be hijacked: 1) You log into your bank. 2) Without logging out or closing the browser first, you go to a hacker-controlled website. 3) The hacker's code requests the cookie for yourbank.com -- it must grab the cookie for that exact domain name. 4) The hacker, within the next 10-15 minutes, uses the cookie to jump into your logged-in session at yourbank.com..
Not so easy. The big problem is how to get you to visit h4x0rh0m3.com with an active session cookie from a known site.
And this is all assuming that yourbank.com doesn't do that extra check to see if your IP changes mid-session... and I'll bet most sites with dangerous access like that do.
Anyway, my post did have the caveat that I did NOT review slashcode before posting.... Honestly, though, slashdot seems to be designed so that you can have as much security as you want, even if that cookie has a hash of sensitive data instead of a temporary session id.
You can control whether your login (held in the cookie) lasts for the browser session only, vs. a whole year. You can also manually logout whenever you want (again, deletes the cookie).
If you do either of those (and don't visit possible cracker-owned sites while you're logged in) you are perfectly safe, since the hacker won't ever be able to see the slashdot cookie.
[I'm assuming that's a hash of the username AND password -- if it's only the username, that's insecure, since the cracker could just figure out the hash algorithm and make cookies from whatever username they wanted.]
Slashdot is unusual in that we have that option (because Taco figures we'll understand it, I guess). In general, sites decide this for you, and don't allow "eternal login" if there's sensitive data at risk -- at most they will save your login name for you (but not the password).
The exploit allows someone to steal any of your domain-based cookies (passwords, private info, etc.) from any website.
Any security hole should be fixed, but this is not as serious as they make it sound.
Passwords? Private info? What serious web developer would be keeps these in a cookie? Cookies are not secure. They are stored unencrypted on the user's hard drive (where they are easily rifled through), and (as mentioned) there have been plenty of bugs in the past that have made their data accessible to John Q. Hacker.
Cookies are mostly used for storing session ids, or another meaningless number that links back to the real info stored in a database on the server (yes, you don't want a hacker reading your session id, but this is a much lower risk).
This is not just for security reasons -- it's because cookies are not reliable. Cookies get wiped out all the time (all browsers that I know of let you delete them, and I see lots of ads for software that offers to manage, delete, filter, or "clean them up" for me.
Also, cookie size is limited (and does this differ on the diff browsers? I know GET request size does), so you could screw yourself over if you were storing a user's personal info and their address was really long.
Why would you store username/password data in a cookie anyway? Most browsers do this for you now, *and* they are more secure about it. Hm.
These are the best practices I was taught, at any rate. I didn't checked slashcode before posting this... and I suppose it is true that best practices are not always followed.
Does anyone have a real sense of how often sensitive data is stored unencrypted in a cookie?
The unpredictable aspects of the legal system are definitely there, though I wouldn't be so paranoid about it as all that.
Either way -- I think I'm going to skip these SCO articles from now on. CRN's interview with McBride was just so frustrating to read -- that guy is such a snake and such a master of spin, it pisses me off to no end, and there's not a thing I can do about it. If this case were going to be resolved anytime soon, I'd stick around to cheer, but as it is, I have no desire to sit around interminably stewing in bile.
What's the practical approach to this? What can a regular, IANAL geek do? Donate to the FSF, since the GPL's getting involved? Somehow I don't think IBM needs my donation to its legal fund. Write letters to editors?
The writer has already offered to manually convert it.
Sure, if he has to, he will. Any solution that doesn't require that work has at least one good thing going for it, though.
And I agree that better XML editing tools would help the pure-XML solution, but there are serious limits to what's possible especially when you're using your own invented tag set. The tool can't check to see if your DDL is well-designed. It can't represent the tag data in any other way (like showing the bolded text instead of the <strong> tags), so you still have to wade through that tag data when trying to edit your content. And you just can't compare auto-completion or even hilight-and-key-shortcut-for-each-tag-pair to just hilighting a whole page and clicking "bulleted list".
I'm not a point-and-click kind of guy either. Almost all of the XML I work with is custom-designed DDL, usu. populated from a database. All of my XSL and HTML is hand-tweaked and sometimes completely hand-written. When I'm writing documentation, though, I always develop the content in an WYSIWYG editor, just because I can't follow a complicated explanation with all those tags in the way, and I don't want to have to constantly think about formatting (and you will have to think about formatting when you structure your XML, just because in the end every structural decision impacts the options you will have when building the presentation).
After all, we're not generating an XML doc here that will be parsed by a computer and pushed into a database or object graph. It's human-targetted documentation. The main thing we're going to use the XML structure for is, in the end, formatting the content.
So why design a DDL for formatting when we already have a standardized one? It has weak points, but it has been thought out, plus now some other writer will be able to work on the docs without learning your DDL. Besides, XHTML has a great advantage over plain HTML in that you can easily automate your tweaks to the formatting with XSL.
With straight XHTML or OOo/AbiWord plus div tags with id/class attributes, what is the advantage? You've got your presentation positively locked into your content, and the id/class attributes aren't any easier to add/manage/read than straight XML (perhaps harder).
No, you're missing out the XSL step.
The id tags are there so that you can alter the presentation if you want to -- just push the thing through a stylesheet that (for example) converts the unordered list to a table with pretty images on the corners if your id attrib = 'chapterSummary'. It's pretty straight-forward. You could also tweak it (to a lesser degree) with CSS.
None of these are ideal solutions, but this seems like the most logical for writing documentation.
Yes -- please be warned that this notorious crime ring definitely already has your vital information!
Fortunately, I work for Citibank's fraud division, and will be able to protect your vital account information if you contact us immediately.
Please click on the link below, which will take you to our Fraud Division. In the form that pops up, you will need to enter your account number, your mother's maiden name, your social security number, your current PIN number (we will change the PIN for you and mail you the new PIN for security). It is important that you provide all of this information so that we can verify your identity and secure your account immediately.
Here is the link: http://www.citibank.com/fraud@www.5ucK3R.co m
Remember -- time is essential!
Sincerely, jtheory Citibank Fraud Investigation Unit
I think we need a solution that is workable with an editor that's designed for writing formatted text. There are just too many benefits to a proper editor (various tools, shortcuts, but especially simplicity of presentation).
Say you're writing a bulleted list with 100 items. In pure XML that's a minimum of 2 tags per item, plus tage for the list. Now put the first word of each item in bold and the rest of the line in italics. This is pretty basic formatting... but you'll have to edit that list while wading among an extra 2800+ chars (assuming very short XML tags). You won't even be able to find your text after a while.
Also don't forget that the writer already has 60 pages, fully formatted in Word. That would be unpleasant to reformat by hand.
I'm skirting your real point so far though, for a reason -- I'm guessing you'd argue that the bulleted list above should just have a tag around the whole thing, like chapterEndSummary, and the stylesheet would control whether it was formatted as a bulleted list, a table with alternating colored rows, or whatever. This doesn't work out well in practice, though. I've spent a lot of time working with XML and XSL, and if you're going to be really flexible about the presentation, you need your data to be very organized (which means lots of tags making your text harder to read!). Think about it. How will you know when each item begins and ends? How will you know which is the word (or words) that will end up bolded in your stylesheet?
Plus you will simply have to make a lot of formatting decisions as you write, because the content would differ depending on the format. If you want more than 20 words or so per item, that bulleted list is going to start looking really ugly.
I would argue for saving the document in XHTML (possibly from OpenOffice - you can import the Word doc). Most of the tags will hold formatting information, but you can toss in class or id attributes into higher-level tags (maybe just divs) so that a stylesheet could modify the formatting below if as desired for specific kinds of content. Your document won't be obsolete even if OpenOffice disappears, and you can still run it through XSL with a lot of flexibility.
Note: I haven't worked with DocBook at all, so I don't know how that might address these issues.
I've never liked that word either. I understand the derivation, ("web log" --> "we blog, yes we do"), but it's just an ugly word.
What other words sound like "blog"? Almost all negative things. To me it always sounds like an amalgam of "blah" and "bog".
Rhyming words, on the negative side: slog hog cog (each bump on a gear is a cog; also slang for a mindless corporate worker) frog (the amphibian, also a slur meaning French person) bog wog (an old brit racial slur) log (various meanings, including scatalogical slang) snog (brit slang for kissing/cuddling, which isn't a bad thing, but I learned it from a movie in which the girl suggesting the snogging was not exactly snog-worthy, so I still have bad associations)
More positive -og words: dog
See what I mean?
Of course, it's much too late to change the word now....
If you come up with a suite of questions. the spammer can come up with a suite of responses.
You (and parent poster) have some good points here. Something you're missing, though -- you're still thinking in terms of a large service that can be reused by lots of websites.
Suppose the system only offered the framework, and you had to provide (and rotate) the questions yourself for your own website. I'm thinking of writing a filter question into my forms, since I hate those text recognition things (my eyesight's not very good, so obscured text with negligible contrast is very difficult to read)... I'd just ask the user to enter in the last word on the bottom of this page, or the name of this website, or something like that.
Because I did it myself, and it's using questions specific to my website, it would be very difficult for a tool to: a) detect that I'm using a filtering mechanism b) answer any of the questions (since they would NOT match familiar patterns) c) successfully submit any form without human attention to configure it.
The weak point of any spambot is that it must scale. It must be able to successfully spam millions of forms to make up for the poor response rate. Anything we can to do defeat scaling will help.
My approach is a little dicey as a general solution, since it depends on the site developer or maintainer to write good questions... any suggestions? What about a field that must be left blank, or the form will be rejected?
Kudos to you for skipping the endless war rehash.:)
I'll clarify.
Litigation in the US currently _is_ often decided by "might makes right", but this is a flaw in the system, since of course it's supposed to be "valid legal case makes right", regardless of might.
So I can cheer because "valid legal case" and "might" are coinciding in this case, since justice will be done -- but I'm cheering for "valid legal case", I'm definitely not cheering for "might".
That's my point -- if you cheer for IBM's might, then you're still on their side even if SCO's case is suddenly miraculously proved true and they have the valid legal case. Yeah, I'd be very upset with the whole situation if that happened, but I'd have to be on SCO's side or I'd be a hypocrite.
Well, that's a nice reminder of how slashcode works. The sig is inserted dynamically, of course (which makes sense since users can choose to hide sigs), so now that you've fixed your sig this whole exchange makes no sense whatsoever. Cruel, cruel to us poor meta-moderators.
What was the original sig with virii in it? I know you fixed the "true measure or a good coder" thing, because I remember noticing the typo in the original one (I was a writing tutor in college for 3 years, and I can't help seeing all errors... but I don't point them out anymore). I like that sig -- it reminds me of this:
"There are two ways of constructing a software design; one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult."
- C. A. R. Hoare
I totally agree that it's cool that Linux is heading to court with a pretty strong case (though I don't think GPL legal precedence will come into SCO's suit at all. SCO is saying that IBM stole their IP; they don't care how IBM released it; they're saying that it wasn't IBM's IP to release in *any* way. Some of the countersuits involve GPL, though).
I have to say I wouldn't celebrate much, though, if IBM won the case because they are "such a giant" with "the right leverage". If SCO's suit is valid, IBM should pay some kind of damages, and offending versions of Linux must be discontinued. Yes, the system doesn't always work right, but law is law and the little guy should win if the case has merit, whether he's hated or cheered for it. If the law is bad, then we have to work to change it.
If I cheer because IBM is huge, I lose the right to complain when MS squashes some small developer under the weight of a thousand lawyers.
Final thought: the elephant is walking the same direction as you for now -- but don't get confused and think you're riding it.
I'm probably wasting my time here... but please read the article and even the post you are responding to.
1) Most posters are *not* arguing conspiracy theories or even illegal acts. Time can remove a single article if they so desire; however, it is difficult to see how this could have been accidental (see below), and I for one would like to know who decided to remove the article, and why.
2) This could not have been an accidental removal or typo as you described. The table of contents for the issue is still available -- this is a single document -- but the link to this one article was removed. Even if there are people such as you described, wandering around Time's archives deleting random, un-backed-up files accidentally, I don't think this person would have have: * accidentally opened this table-of-contents document from 5 years ago * accidentally removed a single link and a few linebreaks * accidentally saved the document * deleted the article document that the link pointed to, and then * lost all memory of these "accidents" and failed to restore the documents from backup.
I've been using Eclipse for about a year for some large J2EE projects, and I've been very happy with it. I had been using JBuilder since version 2 (!), and switched over when the price suddenly became an issue (my employer folded). I've really come to depend on the refactoring support, which is why I can never understand the diehards who refuse to use an IDE.... I always use the latest milestone release (they've all been very stable). IDEA is also well-known as a good refactoring IDE, though I haven't used it due to the price. I tried out NetBeans some time ago (2-3 years ago?) and wasn't fond of it, though I haven't been back to re-evaluate it.
One thing -- if you ever need to get into building Java GUIs, JBuilder still has the best RAD GUI designer that I've seen, in terms of generating sensible code that you can tweak by hand (within limits), and then use the designer again. GridBagLayout code was never intended to be hand-written! I don't spend much time with Java GUIs anymore, but when I need to I always do the initial cut in JBuilder (the Personal version is free).
Word to the wise; the Hawk-man's not a target for the faint of heart. I'll bet you've only read about his scientific achievements. You should read up on how he spends his free time.
He's not the soft-hearted scientist you think he is -- I heard about how he capped a bunch of MIT punks last year in a driveby. Dum-dum clip loaded in his AK-47, bustin out bullets to the beat of the bass... it wasn't a pretty sight for the cleanup crew the next morning.
He'll lay the whole story down for you, here (scroll down to the links for "All My Shootin's be Drivebys").
For some unknown reason, they decided to list them as if they were other, related articles in the paper (as other posters have noted). Bizarre. Hey, the dates on all of those articles is the same!
Something to watch out for: the Scott Adams invention (the most coherent one of the lot!) is only linked to from the first page. They dropped that link from each of the other invention pages.
Slashdot Mirror
I think almost everyone involved agreed (and still agrees) that it would be cool for NetBeans and Eclipse to share a plug-in architecture, and even underlying framework code. It would allow a great leap in pooling OSS development resources, and would be a boon for plug-in developers, which in turn would help to make Java with *free* tools a better platform than competing MS technologies.
I wrote a version control plugin for JBuilder -- yet another IDE with its own plugin architecture -- and I'm currently learning the Eclipse plugin architecture so I can port it... yes, it sure would be nice if I could just deploy it as is to other IDEs!
But... I suspect that the whole merging idea was mostly conceived by management types who got a rude awakening when they started talking to the tool developers and found out what kind of effort it would take to actually do it.
The work involved would be mind-boggling... and it's not the sort of thing that would draw open-source developers. It definitely scratches an itch to implement that feature you've been longing for in your IDE of choice (which is why it's often easy to get lots of contributors to a good IDE; look how quick the Eclipse community grew!). But I'll be damned if I'm going to reimplement the same thing two years later for free.
The next version of any tool after it's been ripped apart and reassembled is usually much worse than the last version, too. I remember when JBuilder first switched to a version written in Java (3.5)... it hurt to see how many important features were broken or removed. Sure, you understand that this will help in the long run, but you don't want to be around while it fights it way back to mature status.
So would Sun and IBM be willing to pay what it would really take to get there? It would have been nice, but I'm not surprised the answer was no.
Sorry to reply my own post... just read that the other kid lost 90 lbs. from regular use of the game.
And the kid who broke the record has a heart rate of 51 beats/sec. A low heartrate doesn't correspond directly to fitness level, but it is related.
Check out the picture -- he's just some regular kid. I was expecting a more... athletic type, I guess. You know, someone who has greate endurance from running cross-country all through high school, or something.
Nope -- he looks like a regular video-gaming kid, but with superhuman determination.
I hope those shoes were comfy. Probably not, though, after 37 hours.
No, the "rules" not there to help the webdesigner. They are a best practice to allow the USER of your site
I think your point was implied in the parent post. What exactly are you disagreeing with?
The rules are intended to help the webmaster, because the webmaster is building the website. These are rules to follow while building websites, right?
Yes, every website is built with a primary goal of serving users, as books are written for readers. The user has no direct use for these rules, though of course when the rules help the webmaster achieve his goals, the user benefits (as does the webmaster, who succeeds in bringing in more traffic/sales/etc.).
As your post and the parent post suggested, the important thing here is to understand how these rules can help you (as a webmaster) achieve your goal of building the most useful and accessible website possible. Once you understand what they offer and how what you do affects your users, you can bend the rules.
/ / ..
I emailed taco my resume from the web cafe. Am I being naive?
(they should hire me; I know how to fix it!)
Actually, that makes me suspect that domain registrars must be pushing pretty hard for this.
Think about it -- a French site would have to register their domain w/ the accents AND the unaccented domain: one to be correct, and the other for the foreigners. An international Japanese company might need dozens of domains, because of the different ways their name is transliterated into various languages.
Hm. It seems like there are going to be a lot of problems that this change can cause, mostly because it's NOT easy to type the chars that will be in some of these URLs. It's not obvious at all how to type an accented e (plus it's different by OS). Why? It's a cause of frustration even for English-only speakers! "So... you will resume sending me your what??" When I was studying French in school, I used to mark all the accents by hand into papers I typed up, after printing them out. It was just so much faster than any other method I found. I can't even imagine how I'd manage to input a URL in cyrillic or pictographs.
The thing is, though... this is the lesser of two evils. I really don't see everyone sharing a common language anytime soon, which would be the other solution. The internet all over the world is swiftly moving from academics and geeks to businesses to common folks, all over the world. Don't you WANT to be able to fully translate your website, so any bumpkin in Siberia can order your products? They aren't all going to learn a new alphabet.
Think about it. Just about every language has its own keyboard layout. All my emails from Europe looked pretty funny until I figured out how to change the keyboard layout... (yes, you can do this in many web cafes. Damn! I can't spell caf-ay without an accent!). Someone somewhere is going to have a tough time typing any given characters.
It's only fair if accessing foreign language sites is an equal pain-in-the-ass for all. The internet is not destined to be a single language medium.
Maybe the operating systems and keyboards need to improve. What a shocking thought that is. Hey, it would be a huge help to lots of frustrated kids trying to do their foreign language homework on a computer.
And really, if you think about it, how many foreign-language URLs do you type in during your day? Sometimes you get a search result that looks interesting so you translate it. Okay... you don't type that URL, you copy it and paste in the translator. Where else do we get URLs? When won't you be able to just copy it? Very rarely...
I think we can deal with it for a while.
Backups will contain the drafts in the future. Some them will surely survive.
There's a weird kind of paradox involved in what will survive, though.
Digital media has that wonderful property that it can be reproduced *perfectly* -- such that the copy is indistinguishable from the original -- but it must be copied or it will die.
You can burn your vacation videos to CD so your grandkids will be able to see them -- but that CD won't be readable anymore in a decade, never mind a century. If you faithfully make sure they're recopied every once in a while, though (and possibly converted to whatever new video formats are invented), your descendants 500 years hence will be able to see you waving from behind that sandcastle in California, as if it were filmed yesterday. No more flipping through yellowed photographs or crumbling newspaper clippings.... Imagine it! A scientist may use your video to prove his point about how the sunsets on the west coast have improved since California sank into the ocean.
He has to use family videos, though, because two decades of scientifically-recorded data on weather patters was all wiped out when a massive electromagnetic bomb was set up by terrorists in 2012.
Yeah, far-fetched example. I don't want to force the point, and definitely lots of stuff will survive... but our progeny won't be making the same kinds of attic discoveries that we can today.
"Hey, viddy all these ancient discs that Old Grampy Limp Devil had cached away up here! Can you run them? Nothing, huh? Oh, well."
I read an interesting article a few years ago about how even our hard copy (books, magazines, musical scores, etc.) won't be nearly as useful to future historians.
Why?
Current historians learn a lot about each writers creative process, and how writers evolved their ideas, from drafts and corrections. Music scholars pore over every scratched-out note, every furious scribbled comment, in Beethoven's draft scores. Writing music was laborious and hugely frustrating for Beethoven, unlike Mozart, who hardly stopped to think and made few if any corrections.
Future scholars won't know any of this stuff, looking back at our work. We use software to edit our work... so when we fix our errors they are gone forever. We change our minds and the original idea disappears in a puff of electrons. An electronic score of a Beethoven symphony only differs from a Mozart concerto in the musical style -- all of the other data is gone.
It's a sobering thought. Where else are we going to get this data? Not letters, because we write emails now, and regularly delete them (intentionally or not). Diaries? Some people still keep them on paper... but many store them on computer, or publish them in blogs (which as discussed will mostly be gone).
Sobering thought isn't it? It's not neccessarily hubris to say we ought to be saving more of this stuff; people a few hundred years from now should be able to learn from our failures, as well as our successes.
I noticed that too... this system seems closer to the role of the Sun in the Icarus story. Icarus' high-tech daddy built him some powerful wings (P2P tools?) that let him fly... but young foolish Icarus got cocky with his new power and flaunted it, challenging the "Gods" -- he flew too high, and got smoked by the Sun. Wings disintegrating, he plummeted from the sky into the unforgiving sea (of lawsuits?). Sploosh.
I wonder what kind of hardware they run the thing on? I'd laugh if were SUN.
Your, not very imaginative I gather.
Hey, now; be nice. I thought I talked about this somewhere, but here's more detail.
You're right that session cookies are a security hole, but it's much harder to use them, because most of the time when you steal them they're useless. Sessions expire, or are closed on log-out.
If you do your banking online, do you log out? Do you close the browser? Or do you even wait 15 minutes before browing to the shadier parts of the internet? Any of those and you're safe.
Here's what would have to happen for your banking session to be hijacked:
1) You log into your bank.
2) Without logging out or closing the browser first, you go to a hacker-controlled website.
3) The hacker's code requests the cookie for yourbank.com -- it must grab the cookie for that exact domain name.
4) The hacker, within the next 10-15 minutes, uses the cookie to jump into your logged-in session at yourbank.com..
Not so easy. The big problem is how to get you to visit h4x0rh0m3.com with an active session cookie from a known site.
And this is all assuming that yourbank.com doesn't do that extra check to see if your IP changes mid-session... and I'll bet most sites with dangerous access like that do.
Heh, aren't brownies the more traditional medium?
Anyway, my post did have the caveat that I did NOT review slashcode before posting.... Honestly, though, slashdot seems to be designed so that you can have as much security as you want, even if that cookie has a hash of sensitive data instead of a temporary session id.
You can control whether your login (held in the cookie) lasts for the browser session only, vs. a whole year. You can also manually logout whenever you want (again, deletes the cookie).
If you do either of those (and don't visit possible cracker-owned sites while you're logged in) you are perfectly safe, since the hacker won't ever be able to see the slashdot cookie.
[I'm assuming that's a hash of the username AND password -- if it's only the username, that's insecure, since the cracker could just figure out the hash algorithm and make cookies from whatever username they wanted.]
Slashdot is unusual in that we have that option (because Taco figures we'll understand it, I guess). In general, sites decide this for you, and don't allow "eternal login" if there's sensitive data at risk -- at most they will save your login name for you (but not the password).
See? No goatse.
The exploit allows someone to steal any of your domain-based cookies (passwords, private info, etc.) from any website.
Any security hole should be fixed, but this is not as serious as they make it sound.
Passwords? Private info? What serious web developer would be keeps these in a cookie? Cookies are not secure. They are stored unencrypted on the user's hard drive (where they are easily rifled through), and (as mentioned) there have been plenty of bugs in the past that have made their data accessible to John Q. Hacker.
Cookies are mostly used for storing session ids, or another meaningless number that links back to the real info stored in a database on the server (yes, you don't want a hacker reading your session id, but this is a much lower risk).
This is not just for security reasons -- it's because cookies are not reliable. Cookies get wiped out all the time (all browsers that I know of let you delete them, and I see lots of ads for software that offers to manage, delete, filter, or "clean them up" for me.
Also, cookie size is limited (and does this differ on the diff browsers? I know GET request size does), so you could screw yourself over if you were storing a user's personal info and their address was really long.
Why would you store username/password data in a cookie anyway? Most browsers do this for you now, *and* they are more secure about it. Hm.
These are the best practices I was taught, at any rate. I didn't checked slashcode before posting this... and I suppose it is true that best practices are not always followed.
Does anyone have a real sense of how often sensitive data is stored unencrypted in a cookie?
The unpredictable aspects of the legal system are definitely there, though I wouldn't be so paranoid about it as all that.
Either way -- I think I'm going to skip these SCO articles from now on. CRN's interview with McBride was just so frustrating to read -- that guy is such a snake and such a master of spin, it pisses me off to no end, and there's not a thing I can do about it. If this case were going to be resolved anytime soon, I'd stick around to cheer, but as it is, I have no desire to sit around interminably stewing in bile.
What's the practical approach to this?
What can a regular, IANAL geek do?
Donate to the FSF, since the GPL's getting involved? Somehow I don't think IBM needs my donation to its legal fund. Write letters to editors?
The writer has already offered to manually convert it.
Sure, if he has to, he will. Any solution that doesn't require that work has at least one good thing going for it, though.
And I agree that better XML editing tools would help the pure-XML solution, but there are serious limits to what's possible especially when you're using your own invented tag set. The tool can't check to see if your DDL is well-designed. It can't represent the tag data in any other way (like showing the bolded text instead of the <strong> tags), so you still have to wade through that tag data when trying to edit your content. And you just can't compare auto-completion or even hilight-and-key-shortcut-for-each-tag-pair to just hilighting a whole page and clicking "bulleted list".
I'm not a point-and-click kind of guy either. Almost all of the XML I work with is custom-designed DDL, usu. populated from a database. All of my XSL and HTML is hand-tweaked and sometimes completely hand-written. When I'm writing documentation, though, I always develop the content in an WYSIWYG editor, just because I can't follow a complicated explanation with all those tags in the way, and I don't want to have to constantly think about formatting (and you will have to think about formatting when you structure your XML, just because in the end every structural decision impacts the options you will have when building the presentation).
After all, we're not generating an XML doc here that will be parsed by a computer and pushed into a database or object graph. It's human-targetted documentation. The main thing we're going to use the XML structure for is, in the end, formatting the content.
So why design a DDL for formatting when we already have a standardized one? It has weak points, but it has been thought out, plus now some other writer will be able to work on the docs without learning your DDL. Besides, XHTML has a great advantage over plain HTML in that you can easily automate your tweaks to the formatting with XSL.
With straight XHTML or OOo/AbiWord plus div tags with id/class attributes, what is the advantage? You've got your presentation positively locked into your content, and the id/class attributes aren't any easier to add/manage/read than straight XML (perhaps harder).
No, you're missing out the XSL step.
The id tags are there so that you can alter the presentation if you want to -- just push the thing through a stylesheet that (for example) converts the unordered list to a table with pretty images on the corners if your id attrib = 'chapterSummary'. It's pretty straight-forward. You could also tweak it (to a lesser degree) with CSS.
None of these are ideal solutions, but this seems like the most logical for writing documentation.
Yes -- please be warned that this notorious crime ring definitely already has your vital information!
o m
Fortunately, I work for Citibank's fraud division, and will be able to protect your vital account information if you contact us immediately.
Please click on the link below, which will take you to our Fraud Division. In the form that pops up, you will need to enter your account number, your mother's maiden name, your social security number, your current PIN number (we will change the PIN for you and mail you the new PIN for security). It is important that you provide all of this information so that we can verify your identity and secure your account immediately.
Here is the link:
http://www.citibank.com/fraud@www.5ucK3R.c
Remember -- time is essential!
Sincerely,
jtheory
Citibank Fraud Investigation Unit
I think we need a solution that is workable with an editor that's designed for writing formatted text. There are just too many benefits to a proper editor (various tools, shortcuts, but especially simplicity of presentation).
Say you're writing a bulleted list with 100 items. In pure XML that's a minimum of 2 tags per item, plus tage for the list. Now put the first word of each item in bold and the rest of the line in italics. This is pretty basic formatting... but you'll have to edit that list while wading among an extra 2800+ chars (assuming very short XML tags). You won't even be able to find your text after a while.
Also don't forget that the writer already has 60 pages, fully formatted in Word. That would be unpleasant to reformat by hand.
I'm skirting your real point so far though, for a reason -- I'm guessing you'd argue that the bulleted list above should just have a tag around the whole thing, like chapterEndSummary, and the stylesheet would control whether it was formatted as a bulleted list, a table with alternating colored rows, or whatever. This doesn't work out well in practice, though. I've spent a lot of time working with XML and XSL, and if you're going to be really flexible about the presentation, you need your data to be very organized (which means lots of tags making your text harder to read!). Think about it. How will you know when each item begins and ends? How will you know which is the word (or words) that will end up bolded in your stylesheet?
Plus you will simply have to make a lot of formatting decisions as you write, because the content would differ depending on the format. If you want more than 20 words or so per item, that bulleted list is going to start looking really ugly.
I would argue for saving the document in XHTML (possibly from OpenOffice - you can import the Word doc). Most of the tags will hold formatting information, but you can toss in class or id attributes into higher-level tags (maybe just divs) so that a stylesheet could modify the formatting below if as desired for specific kinds of content. Your document won't be obsolete even if OpenOffice disappears, and you can still run it through XSL with a lot of flexibility.
Note: I haven't worked with DocBook at all, so I don't know how that might address these issues.
I've never liked that word either. I understand the derivation, ("web log" --> "we blog, yes we do"), but it's just an ugly word.
What other words sound like "blog"? Almost all negative things. To me it always sounds like an amalgam of "blah" and "bog".
Rhyming words, on the negative side:
slog
hog
cog (each bump on a gear is a cog; also slang for a mindless corporate worker)
frog (the amphibian, also a slur meaning French person)
bog
wog (an old brit racial slur)
log (various meanings, including scatalogical slang)
snog (brit slang for kissing/cuddling, which isn't a bad thing, but I learned it from a movie in which the girl suggesting the snogging was not exactly snog-worthy, so I still have bad associations)
More positive -og words:
dog
See what I mean?
Of course, it's much too late to change the word now....
If you come up with a suite of questions. the spammer can come up with a suite of responses.
You (and parent poster) have some good points here. Something you're missing, though -- you're still thinking in terms of a large service that can be reused by lots of websites.
Suppose the system only offered the framework, and you had to provide (and rotate) the questions yourself for your own website. I'm thinking of writing a filter question into my forms, since I hate those text recognition things (my eyesight's not very good, so obscured text with negligible contrast is very difficult to read)... I'd just ask the user to enter in the last word on the bottom of this page, or the name of this website, or something like that.
Because I did it myself, and it's using questions specific to my website, it would be very difficult for a tool to:
a) detect that I'm using a filtering mechanism
b) answer any of the questions (since they would NOT match familiar patterns)
c) successfully submit any form without human attention to configure it.
The weak point of any spambot is that it must scale. It must be able to successfully spam millions of forms to make up for the poor response rate. Anything we can to do defeat scaling will help.
My approach is a little dicey as a general solution, since it depends on the site developer or maintainer to write good questions... any suggestions? What about a field that must be left blank, or the form will be rejected?
Kudos to you for skipping the endless war rehash. :)
I'll clarify.
Litigation in the US currently _is_ often decided by "might makes right", but this is a flaw in the system, since of course it's supposed to be "valid legal case makes right", regardless of might.
So I can cheer because "valid legal case" and "might" are coinciding in this case, since justice will be done -- but I'm cheering for "valid legal case", I'm definitely not cheering for "might".
That's my point -- if you cheer for IBM's might, then you're still on their side even if SCO's case is suddenly miraculously proved true and they have the valid legal case. Yeah, I'd be very upset with the whole situation if that happened, but I'd have to be on SCO's side or I'd be a hypocrite.
Well, that's a nice reminder of how slashcode works. The sig is inserted dynamically, of course (which makes sense since users can choose to hide sigs), so now that you've fixed your sig this whole exchange makes no sense whatsoever. Cruel, cruel to us poor meta-moderators.
What was the original sig with virii in it? I know you fixed the "true measure or a good coder" thing, because I remember noticing the typo in the original one (I was a writing tutor in college for 3 years, and I can't help seeing all errors... but I don't point them out anymore). I like that sig -- it reminds me of this:
"There are two ways of constructing a software design; one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult."
- C. A. R. Hoare
I totally agree that it's cool that Linux is heading to court with a pretty strong case (though I don't think GPL legal precedence will come into SCO's suit at all. SCO is saying that IBM stole their IP; they don't care how IBM released it; they're saying that it wasn't IBM's IP to release in *any* way. Some of the countersuits involve GPL, though).
I have to say I wouldn't celebrate much, though, if IBM won the case because they are "such a giant" with "the right leverage". If SCO's suit is valid, IBM should pay some kind of damages, and offending versions of Linux must be discontinued. Yes, the system doesn't always work right, but law is law and the little guy should win if the case has merit, whether he's hated or cheered for it. If the law is bad, then we have to work to change it.
If I cheer because IBM is huge, I lose the right to complain when MS squashes some small developer under the weight of a thousand lawyers.
Final thought: the elephant is walking the same direction as you for now -- but don't get confused and think you're riding it.
I'm probably wasting my time here...
but please read the article and even the post you are responding to.
1) Most posters are *not* arguing conspiracy theories or even illegal acts. Time can remove a single article if they so desire; however, it is difficult to see how this could have been accidental (see below), and I for one would like to know who decided to remove the article, and why.
2) This could not have been an accidental removal or typo as you described. The table of contents for the issue is still available -- this is a single document -- but the link to this one article was removed. Even if there are people such as you described, wandering around Time's archives deleting random, un-backed-up files accidentally, I don't think this person would have have:
* accidentally opened this table-of-contents document from 5 years ago
* accidentally removed a single link and a few linebreaks
* accidentally saved the document
* deleted the article document that the link pointed to, and then
* lost all memory of these "accidents" and failed to restore the documents from backup.
I've been using Eclipse for about a year for some large J2EE projects, and I've been very happy with it. I had been using JBuilder since version 2 (!), and switched over when the price suddenly became an issue (my employer folded). I've really come to depend on the refactoring support, which is why I can never understand the diehards who refuse to use an IDE.... I always use the latest milestone release (they've all been very stable). IDEA is also well-known as a good refactoring IDE, though I haven't used it due to the price. I tried out NetBeans some time ago (2-3 years ago?) and wasn't fond of it, though I haven't been back to re-evaluate it.
One thing -- if you ever need to get into building Java GUIs, JBuilder still has the best RAD GUI designer that I've seen, in terms of generating sensible code that you can tweak by hand (within limits), and then use the designer again. GridBagLayout code was never intended to be hand-written! I don't spend much time with Java GUIs anymore, but when I need to I always do the initial cut in JBuilder (the Personal version is free).
Word to the wise; the Hawk-man's not a target for the faint of heart. I'll bet you've only read about his scientific achievements. You should read up on how he spends his free time.
He's not the soft-hearted scientist you think he is -- I heard about how he capped a bunch of MIT punks last year in a driveby. Dum-dum clip loaded in his AK-47, bustin out bullets to the beat of the bass... it wasn't a pretty sight for the cleanup crew the next morning.
He'll lay the whole story down for you, here (scroll down to the links for "All My Shootin's be Drivebys").
For some unknown reason, they decided to list them as if they were other, related articles in the paper (as other posters have noted). Bizarre. Hey, the dates on all of those articles is the same!
Something to watch out for: the Scott Adams invention (the most coherent one of the lot!) is only linked to from the first page. They dropped that link from each of the other invention pages.