> The real problem here is NOT the CDDL, Apache License, etc. The real problem is the GPL. There are > many licenses classified as *free software* by the FSF that are incompatible. What makes SUN's any > more evil than the other ones? If Richard's (RMS) criteria for what is free software isn't good > enough to make all *free software* licenses compatible, then perhaps his criteria is wrong?
The problem is not _only_ the GPL. The problem is that different licences can have different restrictions, making the licensed material non-public-domain in different ways. The GPL is one example of a license that includes restrictions, but the CDDL is another. They are incompatible because they include *different* restrictions. Consequently, you can't add code with one license into a project that is distributed under a different license, unless the restrictions of the one license are a strict subset of the restrictions of the other (e.g., you can add BSD-licensed code to a GPL-licensed project, because the BSD license does not contain any restrictions the GPL lacks; the other way around doesn't work, however).
Even the BSD license can be problematic in certain rare situations, e.g., for a clipart collection, wherein the requirement of giving the original source credit constitutes an odious restriction that makes the licensed material unusable for its intended purpose.
So if you write code and you want it to be able to be used by *any* project, totally irrespective of the license that project is under, the best way to accomplish that is to dedicate your code to the public domain, disclaiming any rights you have to restrict its redistribution, modification, or use. If you do that, you allow any project to use your code that wants to do so. Any other set of terms you choose adds more restrictions, and the more restrictions you add the more licenses you will be incompatible with.
RMS wants the GPL to be considered special, in the sense that compatibility with the GPL should be considered more important than compatibility with any other license, so that any license incompatible with the GPL is considered problematic. The truth is that all licenses with any restrictions whatsoever, the GPL certainly included, are potentially problematic.
Some license are deliberately designed to be incompatible with _certain_ other licenses. The article suggests that the CDDL was deliberately designed to be incompatible with the GPL, but irrespective of that it is certainly the case that the GPL is deliberately designed to be incompatible with certain kinds of license -- primarily proprietary ones, but as a side-effect it is also incompatible with various open-source licenses. This follows naturally: when you put restrictions in a license, you make it forward-incompatible with any license that does not include those restrictions, i.e., code under your license cannot be added to a project that uses any license without some of your restrictions.
The GPLv3 will have more restrictions than the GPLv2, so it will be incompatible with more things.
> how long does it take to recompile windows vista?
ISTR that it takes somewhat more than 24 hours, but less than 36. That information is probably a year or more old, though, because I don't remember when I read it. Also, this assumes you've got to recompile the whole thing, not just certain parts. ("Certain parts" would still be a large chunk when it comes to compiling Windows, and would probably take hours, but in some cases they might not have to do the _whole_ thing.)
And yes, that's the problem with building enormous software projects in traditional compiled languages, without strictly enforced policies about dependencies. Recompiling Debian is just about as bad, albeit somewhat different. Microsoft has admitted (circa last spring IIRC) that this is a substantial problem for them, (although the focus of that interview was more about code complexity than compiling time) and that they are working to reduce the interdependencies and separate things into separately-compiled layers. In the same interview they talked about trying to get some of the device drivers out of kernel space and into userland.
Whatever happened to the ways college professors used to handle the attendance issue, back when I was in school in the oh-so-remote mid nineties? They had the same problem then, of students thinking that they could skip class and then just look over somebody else's notes and get most of the benefit, without having to _actually_ show up for a 7:30am class. Professors had all manner of tactics for dealing with this, ranging from the mundane (actually *gasp* taking attendance, or even formally taking 10% of the course grade from class participation, that sort of thing) through the moderately clever (requiring brief two-minute quizzes or other assignments to be completed and handed in during class) to the outright subtle (e.g., just structuring the class in such a way that actually being there really helped you learn the stuff).
Have the schools hired a new breed of professor who are unaware of these possibilities? Are the students smarter than the professors these days?
You're looking for a technological solution to an already-solved social problem that professors have been successfully dealing with for years. Just post the lectures. The professors who give the students their grades will know how to handle the attendance issue. They've been doing it for decades.
Indeed. If the code is as littered with unclosed tags, invalid nesting, font tags nested inside of font tags inside of other font tags, deeply nested tables for no good reason, and similar nonsense as I normally expect from web pages created by non-techies, it's easier and faster to recreate the site from scratch. Just copy and past the text (from a browser to your text editor) and add the markup as you go.
> I'm really curious to see what kind of CSS modifications I'll have to make to support IE7 vs. Firefox. > There are a number of well known hacks for IE6 and it'll be interesting to see how people keep those > in place without jeopardizing the layouts in IE7.
I haven't tried RC1 yet, but I would characterize the CSS support in Beta 3 as "about the same as IE6". The real improvements in IE7 are in terms of security and (finally!) the PNG alpha channel. I'm sure there *are* some CSS improvements, but they don't seem to correspond with any of the things that were bugging me about the IE6 implementation. Maybe I'm just not using the particular parts of CSS that they improved support for. Perhaps they should publish a list of specific portions of CSS that they have implemented in IE7 that weren't in IE6. Then web developers could find the new features and maybe consider taking advantage of them at some point. (For many sites, the PNG alpha channel by itself will be enough reason, once IE7 is officially released, to tell IE6 users they've got to upgrade. If you're doing that anyway, might as well take advantage of whatever CSS the new version can handle, as well.)
Another annoying thing is that IE7's DOM still doesn't support appendChild and its kin in the same way as every other browser, i.e., you can't take content retrieved via XMLHTTPRequest and insert it into the page without a lot of messing around.
> One useless "I moved to Linux, HAHA!" post down, 499 to go.
Allow me to violate your expectations. I used to use Linux, but I've moved away from it. Well, okay, I still have a Linux-based firewall, and administer a number of Linux systems at work, but at home I run FreeBSD. HTH.HAND.
> Really? You can write your extensions in perl, python, and ruby?
Although I am a quite major fan of Perl, I would not choose it, in its current state, for writing extensions to an interactive text editor. It doesn't have the data types for the job: buffers[1], markers, text properties, and so forth. Emacs lisp does.
I have actually considered *writing* buffers and markers for Perl, as a module, but the Perl5 object model doesn't supply some of the things that would make it a realistic project for someone with my amount of free time. The Perl6 object model does, or pretty close at any rate, and I am watching Perl6 development with a certain amount of eagerness. (Yeah, I know, there are at least three _partial_ implementations available now, but although I don't mind being a bit of an early adopter from time to time, I'd kinda like a bit more of a stable platform than is currently present.)
Python, in this regard, doesn't have anything more than Perl. It's more rigorously object-oriented, but I don't see that as a selling point -- Perl's multiparadigmatic approach is a much better fit for my way of thinking, and for the problem at hand Emacs lisp's functional and buffer-oriented approach, with some event-oriented features, seems to do the job quite well.
I can't comment significantly on Ruby. It's still on my to-learn list.
Bear in mind, I'm not saying that Emacs lisp is a better language than these others. (Indeed, it is certainly not, in general terms, a better language than Perl.) I'm only saying it's better suited for extending a text editor.
--- [1] I mean buffers here in the Emacs sense, not in the C sense. Integral to this data type is that
common text operations, including insertion and deletion, can be carried out without causing
any markers to lose their place. This makes whole classes of common and annoying programming
problems just go away. Text properties (basically, metadata that can be applied down to the
character level) are also not to be dismissed lightly.
> If you're coming from emacs, you can set vim to use emacs-style keyboard bindings
Nobody uses Emacs for the keybindings. Indeed, the default keybindings are abysmal (though vim's default keybindings aren't exactly my cup of tea either; in either case, defaults are for people who don't actually care; customizeability is for the rest of us).
> In the end, we discovered that they are both just as feature complete and able to emulate > each other quite well.
Up to a point, yes, but there's a reason you don't see things like Gnus and dismal and tramp and so on and so forth written in vim: vim does not have a good substitute for Emacs lisp. Its customization language may be Turing-complete, but for that matter so is unlambda -- that doesn't mean it makes application development easy.
> that's just how raytraced [shadows] would look: sharp and straight.
That depends on, among other things, the lighting. Use a small number of point-source lights and yeah, shadows are sharp and straight. Throw in some area lights, and the shadows become *much* more realistic.
Of course, area lights also significantly increase the render time. I disagree with the article's ideas about how much CPU power is needed. A couple of years ago I calculated _roughly_ how soon desktop PCs will be able to handle raytracing in realtime for games, and I think the figure I came up with was something like 2050 or thereabouts. That's assuming game graphics continue advancing incrementally ad interim to raise the expectations of the visual results a bit, but I think that's valid.
I'd love to be proved wrong, because raytraced frames look awesome, but I just don't think current CPUs can cut the mustard. Multiple cores help a little, but working with current consumer-grade CPUs you'd need a roomful of small-form-factor systems in your cluster, if you want the game to smoothly handle interesting things like irridescent surfaces, refraction, fog, realistic lighting, complex geometry, and so on.
Of course, my estimate _was_ assuming individual frames had to be traced individually. My understanding of 3D games seems to demand this, since the viewport is always in motion in my experience, but if you had a game with a gameplay paradigm such that it was normal to stand still from time to time, then it might become feasible to throw in raytraced frames when the action slows down enough, and that could perhaps be interesting. That would require that your raytracer use the same object data as the faster engine that handles the picture when things move...
> And with 30 billion on hand, they are in a lot better shape than most of those "conglomerates."
Currently, yes, but they've got all their eggs in one industry.
> The notion that a more efficient microsoft would be one that doesn't "waste" all that money on R&D > for new products, doesn't employ all those programmers, and is in hock for, oh let's say half a > TRILLION dollars is simply insane.
Stated like that, yes, it's insane.
I'm not saying they should cut their R&D to the bone to achieve it (although I realise the article sort of suggests that), but they do have a quite palpable need to diversify. And I'm not saying they should go in debt for half a trillion all at once, but borrowing to invest, although counterintuitive, *can* work for a large business, because the ROI can be much larger than the borrowing interest rate. Care has to be taken, of course, not to get caught out with worthless investments and leftover debt. Still, the tactic can be viable.
> Microsoft IS a bank. Imagine the next windows comes out - they've worked the bugs out of the media > player DRM and applied that technology to a Microsoft wallet type program. Now they offer the > incentive to every home user - FREE WINDOWS with your next system!
What is this, fantasy fiction? They've been working on Windows Media Player for a decade (and it's buggier now than ever before) and on DRM for more than half that long, but with their next OS release due out (theoretically) early next year, you suppose they're going to have the bugs worked out, all of a sudden? Then they're going to give away their flagship product gratis? I've got a better idea: why don't they file chapter 11, since they've got a few billion dollars in short-term investments that can be easily converted to cash? Get real.
No, and Microsoft is not a bank in the usual sense of that term, certainly not in the same sense as Chase Manhattan or Wells Fargo. Owning a large bank has important strategic significance for a very large business.
> Just how much further can a software progam go? Does it crash less often or present cooler graphics? > Is this worth paying for?
Does it have automatic file versioning, so that I can select an individual document (or image or whatever) that I've been working on and roll it back to what it looked like a certain day last month? Does the word processor do grouping-symbol matching like Emacs has done for decades? Is there a translucent on-screen display for notifications that I might need to be able to see but also might need to be able to work through, such as the arrival of a message from a coworker? Can the computer just _tell_ me that I have a message from my mom, like the computer on Star Trek would do? Speaking of Star Trek, why can't I ask for all the information pertaining to a certain topic and _get it_, even if it's an isolated paragraph buried in chapter thirty-something of some book published three decades ago? And where's my paperless office? Back in the eighties I was promised that I wouldn't have to shuffle through reams of hard copy any more, and I'm tired of waiting -- when are we going to get the printing subsystems of our computers hooked up with networking protocols and file format filters and such so that we can take content from any application that supports printing and send it to a fax number that the recipient can have set up however he wants, e.g., to read the thing aloud on his voice mail?
I could easily compile a list of dozens of features I'd like to have in software, that I don't currently have. Some of them are even quite feasible (by which I mean neither NP-Hard nor AI-Complete). Microsoft, of course, is not the only entity that might deliver them to me, but in any case the idea that all research in software has been completed is the most absurd thing I've read today.
Perelman's work is more important -- and FAR more technically difficult -- than what would typically be awarded a Fields medal. The man finished the solution for the geometrization conjecture, quite possibly the largest outstanding math problem throughout the twentieth century, certainly one of the three or four largest. It's like offering Einstein a Bausch & Lomb science award for his work on special relativity. It's recognition he doesn't need. If his proof stands up to scrutiny and proves to be correct (as is generally expected it will do), no further recognition is necessary. Everyone in the field of topology is aware of his work and its importance.
> Yes, because the highest aspiration of any company is to BORROW lots of money, not to, > I don't know, turn a profit.
At the consumer level, borrowing money doesn't gain you anything but debt.
However, when you're talking about billions, and the interest rate you can borrow at is reasonable, you tend to be able to do things with the borrowed money that will turn *quite* a profit. Currently Microsoft is very much a technology company, but with a few hundred billion to invest they could become the type of conglomerate that has its hands in dozens of industries. Just imagine if they took the money that they borrowed at 2-5% interest and bought a large agribusiness firm, a major hotel chain, a couple of casinos, a major bottling company, a movie studio, a travel agency, and maybe a couple of banks. $$$.
Not that I think cutting R&D to the bone is a good way to get there. It's not.
> think of just how much cash flow you could get with 0 expenses in your P&L statement
While you're at it, break up the copyright and trademark assets and sell those off too, piecemeal. I bet I can think of a company or two that would bid on the rights to things like the Excel codebase, for instance. Bonus points if the trademark on the word Excel goes to a _different_ company than the one that gets the actual product. Same deal for Word, and so on and so forth. I wonder if Freespire, or whatever they're calling themselves these days, would bid on the rights to the Windows trademark?
> I can't stand people who call having a big R&D budget wasteful.
Indeed. The attempted hostile buy-out back in the eighties that forced Goodyear to sell off large portions of their R&D (in order to finance a stock buy-back to evade the buyout) was one of the worst things that had ever happened to that company, and similar R&D cuts would be even worse for Microsoft, since they are after all inherently a technology company, making R&D even more important.
Microsoft does have plenty of waste, but R&D isn't where the real fat is there.
OTOH, a hostile buy-out of Microsoft, while it would be bad for Microsoft, might be good for the rest of the world, because it might let some of the competition close the gap a little, which, given the way Microsoft takes advantage of its monopoly position, would surely be a good thing for many.
I have collected a substantial repertoire of voodoo for getting Windows 95 and 98 to function more-or-less as advertised. It ranges from the almost-sane (like never giving up on anything without rebooting at least five times -- I'm convinced there must be race conditions on Windows 9x startup that cause it to only _sometimes_ successfully complete everything it's supposed to) through the seemingly unnecessary (like keeping a backup copy of explorer.exe and putting a line in autoexec.bat that copies it overtop of the copy Windows actually uses every time the computer is started) to the frankly bizarre (like the schenanighans required to get print sharing to interoperate with Windows XP, some of which apparently vary depending on the printer model).
> Why should we readjust our definition just to keep numbers low?
Because if there are more than about ten, elementary school teachers will not be able to use a silly little song to teach the list to their students. Most elementary school teachers believe that such a situation would inevitably lead to the collapse of the entire educational system, since learning the list of the planets is one of the six great pillars of elementary education. The other five are learning the nine holidays (one per month from September through May -- in the US, the most common list is something like Back to School, Halloween, Thanksgiving, Christmas, New Year, Valentine's, St. Patrick's, Earth Day, Memorial Day, but it's not important _which_ holidays, as long as you learn one each month), learning the food groups, learning to solve story problems with unpronounceably-foreign names in them, memorizing long lists of mostly-useless conversion factors (such as the number of yards in a mile, liters in a peck, et cetera, ad infinitum, ad nauseam, ad bedlam), and learning to line yourselves up in alphabetical order by last name even though you don't know the other students' last names. If any one of these six pillars is removed, the whole system could crumble.
The only states[1] that would want this are the ones that generally vote on the liberal side (e.g., California). Most of the conservative states (e.g., Indiana) would be less represented (in terms of electoral votes per capita) in such a system than in the current one, and the swing states would receive much less attention during the campaigns. States with a strong view of States Rights (e.g., all of the southeastern states) would also be philosophically opposed.
Therefore, only the liberal states, cheifly California and New England, would favor this proposal, and their adoption of it is unlikely to have any significant impact on the outcome of national elections, unless some conservative from California runs again (along the lines of Reagan, but in Reagan's case it wouldn't have mattered since he won by clean landslide anyway, both times; I suppose Schwartzenegger could fit in this category if he were a natural-born citizen). Which raises the question of why California would agree to it, since they'd be giving up their ability to swing things in favor of a local conservative should they choose to do so. Sure, they'd do it if they thought that by doing so they could get all the other states (especially ones like Indiana and Idaho and so forth) to agree to it, but... surely they're not naive enough to think that will happen.
The New England states might go for it anyhow, since few of them individually have enough electoral votes to reliably elect a local conservative, even if they wanted to do that (e.g., someone like Giuliani perhaps), without significant help from the swing states, so it would only matter if the election were _very_ close, which, the last two notwithstanding, on the whole does not happen all that often.
But that's not enough states to make the thing meaningful.
Furthermore, it's not such a very good idea anyway, because it would de-emphasize the desires of the moderate and compromising swing states and encourage get-out-the-vote campaigning, catering to the desires of the extreme ends of the spectrum, which would lead us into increased disunity and ultimately civil war. Do you really want the Dems promising in California that they'll make gay marriage legal nationwide, while the GOP promises in Indiana that they'll end abortion once and for all, eliciting enormous cheers from the crowds? Do you want to find out what people will want to do to eachother when that happens? Sounds like no fun whatsoever to me.
I like the electoral college. It forces the politicians to limit themselves to moderate things, things that they can say where conservative and liberal people both have to live nextdoor to one another, with progressives and moderates across the street, and have learned to limit their expectations as a result (e.g., in Ohio). This wasn't the original intention of the electoral college, but it is a wonderful side effect. Let's keep it.
[1] Note that by "states" here I do not mean "people", but since this is a decision that would be made by the states as units, rather than by individual people, that is the more relevant consideration.
> I used to go to a school which used RFID keycards to open doors. In that particular case, it > wasn't even a matter of inches - the card had to be within about two centimeters of the reader.
Cheap reader. It's easily possible to make one that can read from a foot away or more.
What really should be done, if RFID tags are used in passports, is that the passport booklet should be shielded on the cover, so that the tag can only be read when it's open. Then it doesn't matter how powerful the bad guys' readers are unless they're operating at a place where you have to show your passport -- in which case, they could probably read it anyway, with hidden cameras if nothing else, so the RFID wouldn't be introducing any major new problems.
The question isn't how easy it is to change your MAC address, but rather how easy is it to find out what to change the MAC address to. (I'm not sure it's that much harder, though, assuming a device that's normally plugged in is present so you can snoop on it.)
> I would hope no serious security system relied entirely on that one factor
No serious security system relies on *ANY* one factor.
Tying a MAC address to an ethernet port doesn't solve all security-related problems, but it does help somewhat with the specific problem of employees just being generally far too careless about what systems they plug into the LAN, which *can* be a siginficant thing, in some situations.
Obviously you will still want other forms of security.
Here's the thing: you want it to come out 2-3 years *before* you have any really good reasons to upgrade to it. That way there'll be time for a couple of service packs to come out, and if XP is any indication you do NOT want to make the transition until that happens.
Why stop with switch characters, filename delimiter characters, and shell metacharacters, and unprintable characters in filenames? Since files are labelled with their filename in graphical file managers, wouldn't it be great if we could label them with more complicated things? I've caught myself wishing I could get icon labels on a desktop to break across lines at a different place -- i.e., wanting to put line breaks in the filenames. But why stop there? Indeed, why stop at _characters_? Why can't we make one word of a filename bold or italic? Why can't we include pictures or animations?
The reason is, of course, because the filename was not _intended_, when it was developed, to be a visual label for an end user in a graphical environment. It was intended to be a unique identifier that would allow programmers and technical users to distinguish one file from another.
The role needs to be split. New filesystems ought to have a file identifier (which should _not_ be permitted to contain any weird characters) and a file label or description (which _should_ be allowed to contain basically anything). For compatibility reasons, most files would probably start out with obvious correspondences, e.g., a file might be labelled as "some file" in the GUI and have "some_file" as the file ID. But if the user _wanted_ to change the label so that the word "some" is in blue and the word "file" is in green and the whole thing is in Bitstream Vera Serif 32pt italic, then the user would be able to do that _without_ screwing up the file identifier. Indeed, if the user wanted to change the labels on important system files, that should not change the identifier or cause anything to stop working. (Mac users take note: you could re-label your hard drive without screwing anything up.)
Command-line users would probably work directly with the file identifier, but command-line users are inherently more technically-oriented, so that seems reasonable. One supposes there would also be a utility to look for a file by its description and return the identifier so you could do things like
rm `find-by-description JunkFile` (Although one supposes that the utility would have a much shorter name than that.)
As far as the length of the identifier goes, I can't think of a good technical reason to limit that. But there are all _kinds_ of technical reasons to limit what characters it's allowed to contain.
As far as the label or description, its length also should be unlimited, and by that I do *not* mean a measley 256 characters.
> Linux always is, by default (I don't know if you can make it otherwise > without a LOT of hacking).
Very little hacking is required. Mostly you have to use a case-insensitive filesystem instead of a case-sensitive one. Most of the filesystems that are really popular on Linux are case-sensitive, but Linux _supports_ various non-case-sensitive filesystems, most obviously vfat. (The unfortunate thing about vfat is that it doesn't support symlinks, although it certainly could be _made_ to do so (via the.lnk mechanism under the hood, which could be transparent to the user if desired) if some studious programmer were so inclined.)
If you meant, make ext2/3 case-insensitive, then I suppose that might be harder.
Slashdot Mirror
> The real problem here is NOT the CDDL, Apache License, etc. The real problem is the GPL. There are
> many licenses classified as *free software* by the FSF that are incompatible. What makes SUN's any
> more evil than the other ones? If Richard's (RMS) criteria for what is free software isn't good
> enough to make all *free software* licenses compatible, then perhaps his criteria is wrong?
The problem is not _only_ the GPL. The problem is that different licences can have different restrictions, making the licensed material non-public-domain in different ways. The GPL is one example of a license that includes restrictions, but the CDDL is another. They are incompatible because they include *different* restrictions. Consequently, you can't add code with one license into a project that is distributed under a different license, unless the restrictions of the one license are a strict subset of the restrictions of the other (e.g., you can add BSD-licensed code to a GPL-licensed project, because the BSD license does not contain any restrictions the GPL lacks; the other way around doesn't work, however).
Even the BSD license can be problematic in certain rare situations, e.g., for a clipart collection, wherein the requirement of giving the original source credit constitutes an odious restriction that makes the licensed material unusable for its intended purpose.
So if you write code and you want it to be able to be used by *any* project, totally irrespective of the license that project is under, the best way to accomplish that is to dedicate your code to the public domain, disclaiming any rights you have to restrict its redistribution, modification, or use. If you do that, you allow any project to use your code that wants to do so. Any other set of terms you choose adds more restrictions, and the more restrictions you add the more licenses you will be incompatible with.
RMS wants the GPL to be considered special, in the sense that compatibility with the GPL should be considered more important than compatibility with any other license, so that any license incompatible with the GPL is considered problematic. The truth is that all licenses with any restrictions whatsoever, the GPL certainly included, are potentially problematic.
Some license are deliberately designed to be incompatible with _certain_ other licenses. The article suggests that the CDDL was deliberately designed to be incompatible with the GPL, but irrespective of that it is certainly the case that the GPL is deliberately designed to be incompatible with certain kinds of license -- primarily proprietary ones, but as a side-effect it is also incompatible with various open-source licenses. This follows naturally: when you put restrictions in a license, you make it forward-incompatible with any license that does not include those restrictions, i.e., code under your license cannot be added to a project that uses any license without some of your restrictions.
The GPLv3 will have more restrictions than the GPLv2, so it will be incompatible with more things.
> Solid crap? or solid gold?
Actually, I think it's partly iron and partly baked clay. HTH.HAND.
(Yes, there's an actual reference there to get.)
> how long does it take to recompile windows vista?
ISTR that it takes somewhat more than 24 hours, but less than 36. That information is probably a year or more old, though, because I don't remember when I read it. Also, this assumes you've got to recompile the whole thing, not just certain parts. ("Certain parts" would still be a large chunk when it comes to compiling Windows, and would probably take hours, but in some cases they might not have to do the _whole_ thing.)
And yes, that's the problem with building enormous software projects in traditional compiled languages, without strictly enforced policies about dependencies. Recompiling Debian is just about as bad, albeit somewhat different. Microsoft has admitted (circa last spring IIRC) that this is a substantial problem for them, (although the focus of that interview was more about code complexity than compiling time) and that they are working to reduce the interdependencies and separate things into separately-compiled layers. In the same interview they talked about trying to get some of the device drivers out of kernel space and into userland.
Whatever happened to the ways college professors used to handle the attendance issue, back when I was in school in the oh-so-remote mid nineties? They had the same problem then, of students thinking that they could skip class and then just look over somebody else's notes and get most of the benefit, without having to _actually_ show up for a 7:30am class. Professors had all manner of tactics for dealing with this, ranging from the mundane (actually *gasp* taking attendance, or even formally taking 10% of the course grade from class participation, that sort of thing) through the moderately clever (requiring brief two-minute quizzes or other assignments to be completed and handed in during class) to the outright subtle (e.g., just structuring the class in such a way that actually being there really helped you learn the stuff).
Have the schools hired a new breed of professor who are unaware of these possibilities? Are the students smarter than the professors these days?
You're looking for a technological solution to an already-solved social problem that professors have been successfully dealing with for years. Just post the lectures. The professors who give the students their grades will know how to handle the attendance issue. They've been doing it for decades.
Indeed. If the code is as littered with unclosed tags, invalid nesting, font tags nested inside of font tags inside of other font tags, deeply nested tables for no good reason, and similar nonsense as I normally expect from web pages created by non-techies, it's easier and faster to recreate the site from scratch. Just copy and past the text (from a browser to your text editor) and add the markup as you go.
> I'm really curious to see what kind of CSS modifications I'll have to make to support IE7 vs. Firefox.
> There are a number of well known hacks for IE6 and it'll be interesting to see how people keep those
> in place without jeopardizing the layouts in IE7.
I haven't tried RC1 yet, but I would characterize the CSS support in Beta 3 as "about the same as IE6". The real improvements in IE7 are in terms of security and (finally!) the PNG alpha channel. I'm sure there *are* some CSS improvements, but they don't seem to correspond with any of the things that were bugging me about the IE6 implementation. Maybe I'm just not using the particular parts of CSS that they improved support for. Perhaps they should publish a list of specific portions of CSS that they have implemented in IE7 that weren't in IE6. Then web developers could find the new features and maybe consider taking advantage of them at some point. (For many sites, the PNG alpha channel by itself will be enough reason, once IE7 is officially released, to tell IE6 users they've got to upgrade. If you're doing that anyway, might as well take advantage of whatever CSS the new version can handle, as well.)
Another annoying thing is that IE7's DOM still doesn't support appendChild and its kin in the same way as every other browser, i.e., you can't take content retrieved via XMLHTTPRequest and insert it into the page without a lot of messing around.
> One useless "I moved to Linux, HAHA!" post down, 499 to go.
Allow me to violate your expectations. I used to use Linux, but I've moved away from it. Well, okay, I still have a Linux-based firewall, and administer a number of Linux systems at work, but at home I run FreeBSD. HTH.HAND.
> Really? You can write your extensions in perl, python, and ruby?
Although I am a quite major fan of Perl, I would not choose it, in its current state, for writing extensions to an interactive text editor. It doesn't have the data types for the job: buffers[1], markers, text properties, and so forth. Emacs lisp does.
I have actually considered *writing* buffers and markers for Perl, as a module, but the Perl5 object model doesn't supply some of the things that would make it a realistic project for someone with my amount of free time. The Perl6 object model does, or pretty close at any rate, and I am watching Perl6 development with a certain amount of eagerness. (Yeah, I know, there are at least three _partial_ implementations available now, but although I don't mind being a bit of an early adopter from time to time, I'd kinda like a bit more of a stable platform than is currently present.)
Python, in this regard, doesn't have anything more than Perl. It's more rigorously object-oriented, but I don't see that as a selling point -- Perl's multiparadigmatic approach is a much better fit for my way of thinking, and for the problem at hand Emacs lisp's functional and buffer-oriented approach, with some event-oriented features, seems to do the job quite well.
I can't comment significantly on Ruby. It's still on my to-learn list.
Bear in mind, I'm not saying that Emacs lisp is a better language than these others. (Indeed, it is certainly not, in general terms, a better language than Perl.) I'm only saying it's better suited for extending a text editor.
---
[1] I mean buffers here in the Emacs sense, not in the C sense. Integral to this data type is that
common text operations, including insertion and deletion, can be carried out without causing
any markers to lose their place. This makes whole classes of common and annoying programming
problems just go away. Text properties (basically, metadata that can be applied down to the
character level) are also not to be dismissed lightly.
> If you're coming from emacs, you can set vim to use emacs-style keyboard bindings
Nobody uses Emacs for the keybindings. Indeed, the default keybindings are abysmal (though vim's default keybindings aren't exactly my cup of tea either; in either case, defaults are for people who don't actually care; customizeability is for the rest of us).
> In the end, we discovered that they are both just as feature complete and able to emulate
> each other quite well.
Up to a point, yes, but there's a reason you don't see things like Gnus and dismal and tramp and so on and so forth written in vim: vim does not have a good substitute for Emacs lisp. Its customization language may be Turing-complete, but for that matter so is unlambda -- that doesn't mean it makes application development easy.
> that's just how raytraced [shadows] would look: sharp and straight.
That depends on, among other things, the lighting. Use a small number of point-source lights and yeah, shadows are sharp and straight. Throw in some area lights, and the shadows become *much* more realistic.
Of course, area lights also significantly increase the render time. I disagree with the article's ideas about how much CPU power is needed. A couple of years ago I calculated _roughly_ how soon desktop PCs will be able to handle raytracing in realtime for games, and I think the figure I came up with was something like 2050 or thereabouts. That's assuming game graphics continue advancing incrementally ad interim to raise the expectations of the visual results a bit, but I think that's valid.
I'd love to be proved wrong, because raytraced frames look awesome, but I just don't think current CPUs can cut the mustard. Multiple cores help a little, but working with current consumer-grade CPUs you'd need a roomful of small-form-factor systems in your cluster, if you want the game to smoothly handle interesting things like irridescent surfaces, refraction, fog, realistic lighting, complex geometry, and so on.
Of course, my estimate _was_ assuming individual frames had to be traced individually. My understanding of 3D games seems to demand this, since the viewport is always in motion in my experience, but if you had a game with a gameplay paradigm such that it was normal to stand still from time to time, then it might become feasible to throw in raytraced frames when the action slows down enough, and that could perhaps be interesting. That would require that your raytracer use the same object data as the faster engine that handles the picture when things move...
> And with 30 billion on hand, they are in a lot better shape than most of those "conglomerates."
Currently, yes, but they've got all their eggs in one industry.
> The notion that a more efficient microsoft would be one that doesn't "waste" all that money on R&D
> for new products, doesn't employ all those programmers, and is in hock for, oh let's say half a
> TRILLION dollars is simply insane.
Stated like that, yes, it's insane.
I'm not saying they should cut their R&D to the bone to achieve it (although I realise the article sort of suggests that), but they do have a quite palpable need to diversify. And I'm not saying they should go in debt for half a trillion all at once, but borrowing to invest, although counterintuitive, *can* work for a large business, because the ROI can be much larger than the borrowing interest rate. Care has to be taken, of course, not to get caught out with worthless investments and leftover debt. Still, the tactic can be viable.
> Microsoft IS a bank. Imagine the next windows comes out - they've worked the bugs out of the media
> player DRM and applied that technology to a Microsoft wallet type program. Now they offer the
> incentive to every home user - FREE WINDOWS with your next system!
What is this, fantasy fiction? They've been working on Windows Media Player for a decade (and it's buggier now than ever before) and on DRM for more than half that long, but with their next OS release due out (theoretically) early next year, you suppose they're going to have the bugs worked out, all of a sudden? Then they're going to give away their flagship product gratis? I've got a better idea: why don't they file chapter 11, since they've got a few billion dollars in short-term investments that can be easily converted to cash? Get real.
No, and Microsoft is not a bank in the usual sense of that term, certainly not in the same sense as Chase Manhattan or Wells Fargo. Owning a large bank has important strategic significance for a very large business.
> Just how much further can a software progam go? Does it crash less often or present cooler graphics?
> Is this worth paying for?
Does it have automatic file versioning, so that I can select an individual document (or image or whatever) that I've been working on and roll it back to what it looked like a certain day last month? Does the word processor do grouping-symbol matching like Emacs has done for decades? Is there a translucent on-screen display for notifications that I might need to be able to see but also might need to be able to work through, such as the arrival of a message from a coworker? Can the computer just _tell_ me that I have a message from my mom, like the computer on Star Trek would do? Speaking of Star Trek, why can't I ask for all the information pertaining to a certain topic and _get it_, even if it's an isolated paragraph buried in chapter thirty-something of some book published three decades ago? And where's my paperless office? Back in the eighties I was promised that I wouldn't have to shuffle through reams of hard copy any more, and I'm tired of waiting -- when are we going to get the printing subsystems of our computers hooked up with networking protocols and file format filters and such so that we can take content from any application that supports printing and send it to a fax number that the recipient can have set up however he wants, e.g., to read the thing aloud on his voice mail?
I could easily compile a list of dozens of features I'd like to have in software, that I don't currently have. Some of them are even quite feasible (by which I mean neither NP-Hard nor AI-Complete). Microsoft, of course, is not the only entity that might deliver them to me, but in any case the idea that all research in software has been completed is the most absurd thing I've read today.
Perelman's work is more important -- and FAR more technically difficult -- than what would typically be awarded a Fields medal. The man finished the solution for the geometrization conjecture, quite possibly the largest outstanding math problem throughout the twentieth century, certainly one of the three or four largest. It's like offering Einstein a Bausch & Lomb science award for his work on special relativity. It's recognition he doesn't need. If his proof stands up to scrutiny and proves to be correct (as is generally expected it will do), no further recognition is necessary. Everyone in the field of topology is aware of his work and its importance.
> Yes, because the highest aspiration of any company is to BORROW lots of money, not to,
> I don't know, turn a profit.
At the consumer level, borrowing money doesn't gain you anything but debt.
However, when you're talking about billions, and the interest rate you can borrow at is reasonable, you tend to be able to do things with the borrowed money that will turn *quite* a profit. Currently Microsoft is very much a technology company, but with a few hundred billion to invest they could become the type of conglomerate that has its hands in dozens of industries. Just imagine if they took the money that they borrowed at 2-5% interest and bought a large agribusiness firm, a major hotel chain, a couple of casinos, a major bottling company, a movie studio, a travel agency, and maybe a couple of banks. $$$.
Not that I think cutting R&D to the bone is a good way to get there. It's not.
> think of just how much cash flow you could get with 0 expenses in your P&L statement
While you're at it, break up the copyright and trademark assets and sell those off too, piecemeal. I bet I can think of a company or two that would bid on the rights to things like the Excel codebase, for instance. Bonus points if the trademark on the word Excel goes to a _different_ company than the one that gets the actual product. Same deal for Word, and so on and so forth. I wonder if Freespire, or whatever they're calling themselves these days, would bid on the rights to the Windows trademark?
> I can't stand people who call having a big R&D budget wasteful.
Indeed. The attempted hostile buy-out back in the eighties that forced Goodyear to sell off large portions of their R&D (in order to finance a stock buy-back to evade the buyout) was one of the worst things that had ever happened to that company, and similar R&D cuts would be even worse for Microsoft, since they are after all inherently a technology company, making R&D even more important.
Microsoft does have plenty of waste, but R&D isn't where the real fat is there.
OTOH, a hostile buy-out of Microsoft, while it would be bad for Microsoft, might be good for the rest of the world, because it might let some of the competition close the gap a little, which, given the way Microsoft takes advantage of its monopoly position, would surely be a good thing for many.
I have collected a substantial repertoire of voodoo for getting Windows 95 and 98 to function more-or-less as advertised. It ranges from the almost-sane (like never giving up on anything without rebooting at least five times -- I'm convinced there must be race conditions on Windows 9x startup that cause it to only _sometimes_ successfully complete everything it's supposed to) through the seemingly unnecessary (like keeping a backup copy of explorer.exe and putting a line in autoexec.bat that copies it overtop of the copy Windows actually uses every time the computer is started) to the frankly bizarre (like the schenanighans required to get print sharing to interoperate with Windows XP, some of which apparently vary depending on the printer model).
> Why should we readjust our definition just to keep numbers low?
Because if there are more than about ten, elementary school teachers will not be able to use a silly little song to teach the list to their students. Most elementary school teachers believe that such a situation would inevitably lead to the collapse of the entire educational system, since learning the list of the planets is one of the six great pillars of elementary education. The other five are learning the nine holidays (one per month from September through May -- in the US, the most common list is something like Back to School, Halloween, Thanksgiving, Christmas, New Year, Valentine's, St. Patrick's, Earth Day, Memorial Day, but it's not important _which_ holidays, as long as you learn one each month), learning the food groups, learning to solve story problems with unpronounceably-foreign names in them, memorizing long lists of mostly-useless conversion factors (such as the number of yards in a mile, liters in a peck, et cetera, ad infinitum, ad nauseam, ad bedlam), and learning to line yourselves up in alphabetical order by last name even though you don't know the other students' last names. If any one of these six pillars is removed, the whole system could crumble.
Or, erhm, something like that.
The only states[1] that would want this are the ones that generally vote on the liberal side (e.g., California). Most of the conservative states (e.g., Indiana) would be less represented (in terms of electoral votes per capita) in such a system than in the current one, and the swing states would receive much less attention during the campaigns. States with a strong view of States Rights (e.g., all of the southeastern states) would also be philosophically opposed.
Therefore, only the liberal states, cheifly California and New England, would favor this proposal, and their adoption of it is unlikely to have any significant impact on the outcome of national elections, unless some conservative from California runs again (along the lines of Reagan, but in Reagan's case it wouldn't have mattered since he won by clean landslide anyway, both times; I suppose Schwartzenegger could fit in this category if he were a natural-born citizen). Which raises the question of why California would agree to it, since they'd be giving up their ability to swing things in favor of a local conservative should they choose to do so. Sure, they'd do it if they thought that by doing so they could get all the other states (especially ones like Indiana and Idaho and so forth) to agree to it, but... surely they're not naive enough to think that will happen.
The New England states might go for it anyhow, since few of them individually have enough electoral votes to reliably elect a local conservative, even if they wanted to do that (e.g., someone like Giuliani perhaps), without significant help from the swing states, so it would only matter if the election were _very_ close, which, the last two notwithstanding, on the whole does not happen all that often.
But that's not enough states to make the thing meaningful.
Furthermore, it's not such a very good idea anyway, because it would de-emphasize the desires of the moderate and compromising swing states and encourage get-out-the-vote campaigning, catering to the desires of the extreme ends of the spectrum, which would lead us into increased disunity and ultimately civil war. Do you really want the Dems promising in California that they'll make gay marriage legal nationwide, while the GOP promises in Indiana that they'll end abortion once and for all, eliciting enormous cheers from the crowds? Do you want to find out what people will want to do to eachother when that happens? Sounds like no fun whatsoever to me.
I like the electoral college. It forces the politicians to limit themselves to moderate things, things that they can say where conservative and liberal people both have to live nextdoor to one another, with progressives and moderates across the street, and have learned to limit their expectations as a result (e.g., in Ohio). This wasn't the original intention of the electoral college, but it is a wonderful side effect. Let's keep it.
[1] Note that by "states" here I do not mean "people", but since this is a decision that would be made by the states as units, rather than by individual people, that is the more relevant consideration.
> I used to go to a school which used RFID keycards to open doors. In that particular case, it
> wasn't even a matter of inches - the card had to be within about two centimeters of the reader.
Cheap reader. It's easily possible to make one that can read from a foot away or more.
What really should be done, if RFID tags are used in passports, is that the passport booklet should be shielded on the cover, so that the tag can only be read when it's open. Then it doesn't matter how powerful the bad guys' readers are unless they're operating at a place where you have to show your passport -- in which case, they could probably read it anyway, with hidden cameras if nothing else, so the RFID wouldn't be introducing any major new problems.
> Uh, go wireless?
All these doors and windows are potential entry points into our fortress! How can we manage protecting against unwanted invasions at all those points?
I know, we'll get rid of the walls, and then there won't *be* any doors or windows!
Given how easy it is to change your mac address
The question isn't how easy it is to change your MAC address, but rather how easy is it to find out what to change the MAC address to. (I'm not sure it's that much harder, though, assuming a device that's normally plugged in is present so you can snoop on it.)
> I would hope no serious security system relied entirely on that one factor
No serious security system relies on *ANY* one factor.
Tying a MAC address to an ethernet port doesn't solve all security-related problems, but it does help somewhat with the specific problem of employees just being generally far too careless about what systems they plug into the LAN, which *can* be a siginficant thing, in some situations.
Obviously you will still want other forms of security.
> a reason to actually upgrade to it by then?
Here's the thing: you want it to come out 2-3 years *before* you have any really good reasons to upgrade to it. That way there'll be time for a couple of service packs to come out, and if XP is any indication you do NOT want to make the transition until that happens.
Why stop with switch characters, filename delimiter characters, and shell metacharacters, and unprintable characters in filenames? Since files are labelled with their filename in graphical file managers, wouldn't it be great if we could label them with more complicated things? I've caught myself wishing I could get icon labels on a desktop to break across lines at a different place -- i.e., wanting to put line breaks in the filenames. But why stop there? Indeed, why stop at _characters_? Why can't we make one word of a filename bold or italic? Why can't we include pictures or animations?
The reason is, of course, because the filename was not _intended_, when it was developed, to be a visual label for an end user in a graphical environment. It was intended to be a unique identifier that would allow programmers and technical users to distinguish one file from another.
The role needs to be split. New filesystems ought to have a file identifier (which should _not_ be permitted to contain any weird characters) and a file label or description (which _should_ be allowed to contain basically anything). For compatibility reasons, most files would probably start out with obvious correspondences, e.g., a file might be labelled as "some file" in the GUI and have "some_file" as the file ID. But if the user _wanted_ to change the label so that the word "some" is in blue and the word "file" is in green and the whole thing is in Bitstream Vera Serif 32pt italic, then the user would be able to do that _without_ screwing up the file identifier. Indeed, if the user wanted to change the labels on important system files, that should not change the identifier or cause anything to stop working. (Mac users take note: you could re-label your hard drive without screwing anything up.)
Command-line users would probably work directly with the file identifier, but command-line users are inherently more technically-oriented, so that seems reasonable. One supposes there would also be a utility to look for a file by its description and return the identifier so you could do things like
rm `find-by-description JunkFile`
(Although one supposes that the utility would have a much shorter name than that.)
As far as the length of the identifier goes, I can't think of a good technical reason to limit that. But there are all _kinds_ of technical reasons to limit what characters it's allowed to contain.
As far as the label or description, its length also should be unlimited, and by that I do *not* mean a measley 256 characters.
> Linux always is, by default (I don't know if you can make it otherwise
.lnk mechanism under the hood, which could be transparent to the user if desired) if some studious programmer were so inclined.)
> without a LOT of hacking).
Very little hacking is required. Mostly you have to use a case-insensitive filesystem instead of a case-sensitive one. Most of the filesystems that are really popular on Linux are case-sensitive, but Linux _supports_ various non-case-sensitive filesystems, most obviously vfat. (The unfortunate thing about vfat is that it doesn't support symlinks, although it certainly could be _made_ to do so (via the
If you meant, make ext2/3 case-insensitive, then I suppose that might be harder.