That's because if the breakup goes through, Microsoft will have to play fair...
And, as we all know, they've never been able to win on merit, so it should be interesting to see what they do.
P.S. I'd love to debate this with any rabid MS fanatics who think Windows is the greatest thing since sliced bread, but it might be too easy. Bring it on. --- pb Reply or e-mail; don't vaguely moderate.
Omitting white space really does speed it up; that's because the first thing the Perl interpreter has to do is read in the file, and if the file is shorter, it has to read less. If you *must* use some spaces, then pad it at the end and align it to a 4096 byte boundary (or at least 512 bytes). Also, when the code is tokenized, you don't have to ignore as much whitespace, or allocate as much memory as a buffer. All of these are improvements.
Enforced scope is fine, if you only need a variable in that scope; that's what my is for. But why always deallocate and allocate off the stack when you can have a few permanent, reusable memory locations? This is especially true for replacing extra loop counters, or getting rid of variable allocation in tight loops or small subroutines. Why be so wasteful?
Also, $m is a variable, and probably a mnemonic as well. $m2 is another $m distinct from the first. $mt2 is probably a temp variable, maybe for $m2. See the simple yet concise variable naming scheme at work?
So I suppose this self-taught programmer also considered comments and documentation to be a waste of disk space? I'm sorry, I've done that before. Managed to delete a lot of silly code, too... --- pb Reply or e-mail; don't vaguely moderate.
Never mind that Joe Average generally doesn't need nearly that much power for all the things he really needs to do. Any home computer sold in the past 15 years can easily do word processing and spreadsheets, even a Pentium 133 plays mp3's with some cycles left to spare, and unless you're still using that 386, your modem is the bottleneck in browsing the web, not your processor, no matter what Intel tells you... --- pb Reply or e-mail; don't vaguely moderate.
Use it for automated, batched transfers. Use it for mail and newsgroups. Maybe use it for ftping large files.
But for god's sake, don't use it to browse the web, unless you plan to use your web browser like an Off-Line Reader... --- pb Reply or e-mail; don't vaguely moderate.
Troll stories at troll times; what will they think of next?
Man, I'm only reading slashdot at night if I can help it now; the WTO will never restrict my pancakes, right, ninjas??? --- pb Reply or e-mail; don't vaguely moderate.
First, I'd like to know just how much "Open Source" code was lifted, and from where.
If it's from X, well, that's cool (BSD-style). If it's from the Linux Kernel, that would probably not be cool (likely just GPLed). I guess we'll see when it comes out, but the reference to 'strict licensing terms' makes me a little leery.
Also, could they pick a new name before it comes out, please? Between MIT's Project Athena, and AtheOS, I'm confused already.
Until then, that's the most kick-ass version of twm I've ever seen, and at the moment it looks like they went through a lot of work to implement essentially a new version of Enlightenment on top of Linux; until they expand their platform support a bit I won't be that impressed. --- pb Reply or e-mail; don't vaguely moderate.
As long as it can hold at least a GB or two, that's more than enough for me. I don't know if I'd want to pay ~$400 for it, though; I'd definitely pay $200.
As to the interface, I'm sure that'll get reverse-engineered soon enough, but it'd be much nicer if it didn't have to; there's no reason to develop a proprietary protocol for this. Heck, what's wrong with ftp? --- pb Reply or e-mail; don't vaguely moderate.
Wow. Ten ideas that made it big for a short period of time, and then got superceded by other new ideas. Big deal.
They got outcompeted; they served their time, and now they're relegated to their technological niches. The implementation is outmoded, but the idea lives on. That's how unnatural selection works; it's technological Darwinism. --- pb Reply or e-mail; don't vaguely moderate.
No, winamp is a proprietary API, and they're both reinventing the wheel. All you have to do is statically link GTK, and there's no difference from the perspective of an outside user.
What you'd need to do is create a GTK wrapper for Win32; then you could thunk through all the calls you need, and port all the GTK stuff to (mostly) native Windows.
In fact, I'd want wrappers for everything to a target API, personally, so I could port everything, and make it all themeable. But it'd be a lot of work...
Also, you don't need efficiency in an IM client; otherwise, people would never write them in Java and Tcl/Tk.:) --- pb Reply or e-mail; don't vaguely moderate.
The "Standard GUI" argument doesn't mean much to me, and it means even less when you don't have to compile it yourself, and you don't know what gets installed on your system--like your average Windows user.:) --- pb Reply or e-mail; don't vaguely moderate.
Hey, thanks! If I had found that earlier, it would have saved me some time.:)
So basically, we still need to standardize the 'IMX' protocol; that's the one thing that document explicitly doesn't cover. And it looks like the only perspective on what to support comes from RFCs 2778 and 2779... --- pb Reply or e-mail; don't vaguely moderate.
Well, I'm not quite sure why the FCC thinks they'd know about this area, but I'm pretty sure they're just overseeing the merger, and not drafting the standard. It's a little creepy, but not as creepy as letting The Secret Service handle Computer Crime.
I wish E-mail programs were interoperable; as it is, I see a lot of MIME headers that break elm. But usually that's just spam; only occasionally is it from real people (users of OutLook) that don't know how to send *text*...
These guys wrote RFC2778 and RFC2779; it seems to be designed from an "agent" perspective. I suppose that's the new, hot trend nowadays, but it seems a little heavyweight for just a chat client. However, they're working on it and I'm not, so I suppose I can't complain.:)
Does anyone know about any other RFCs related to this? --- pb Reply or e-mail; don't vaguely moderate.
Have you tried The GIMP (under Win32) lately? GTK for Windows seems pretty decent.
Of course, a lot of the Windows port stuff is pretty beta-ish. As in, all the basic command-line stuff seems to work, and maybe you could compile X applications under Windows with cygwin, but the port of XFree86 itself is definitely alpha.
I'd love to see more skins for Whistler, since there are only two at the moment: one looks just like Win95/98, and the other one sucks. Hard. --- pb Reply or e-mail; don't vaguely moderate.
Actually, unlike the misleading/. blurb, this would involve the creation of an "industry standard" that AOL-TW would have to adopt.
Sounds good to me. I mean, really, how many stupid datagram headers can you have anyhow? I implemented tftp recently, and that wasn't hard at all.
I say we do this the old-fashioned way. Draft a standard, and write an RFC. We shouldn't need more than 5-7 actual commands anyhow. --- pb Reply or e-mail; don't vaguely moderate.
That's true; but if they don't tell me about it, I won't know to be upset; ignorance is bliss, and all.:)
Hey, if I'm done working on it, and other people aren't, so be it. That's when you appoint a maintainer and do other stuff. But at least I'll have the ability to browse through it later at my leisure, and see what's new, and be proud of what I started.... --- pb Reply or e-mail; don't vaguely moderate.
Well, either you need that, or you need a lot of man-hours to support as much stuff as Linux does, and a whole lot of information that certain hardware companies often don't give you...
In any case, it couldn't hurt. I mentioned this because BeOS didn't support my old video card... --- pb Reply or e-mail; don't vaguely moderate.
I think the question is, what if everyone could share code? The BSD License makes it so that everyone can have the code; the GPL makes it so that everyone has to share.
And I think that Linux would get another journaling filesystem, and maybe some threaded C libraries, and that would kick ass. And BeOS would get a whole lot of drivers, which would also be very cool. And maybe they could eventually merge together.
Although it'd be more unlikely for Linux and "Linux projects" (which often tend to compile on other Unixes as well) to switch to *BSD, I think what you'd see is a lot more code sharing, but then you'd have corporations involved as well. That would be the big difference.
I don't think it's going to actually happen, mind you, but being able to share code is definitely a good thing, and also the point of free licenses. It's a shame that these two are incompatible, but they also have different goals.
I'm not a BSD user because developments like MacOS X make me uncomfortable. It's an ideological difference. I don't like the idea of someone modifying my code and not showing me what they did. I'd like to know, in the same way that a playwright would like to know if you changed the Third Act on him while producing his play, and then made money on it, and told everyone else that it was "your play" now, based on their play, but only your company had rights to your version... --- pb Reply or e-mail; don't vaguely moderate.
However, I remember an Othello game for the Apple II; I think it moved randomly. Therefore, I could almost always win, even back then. So I don't see the advantage.
Try again; you won't be able to seduce me to your wicked ways!
Slashdot Mirror
Ballmer is right.
That's because if the breakup goes through, Microsoft will have to play fair...
And, as we all know, they've never been able to win on merit, so it should be interesting to see what they do.
P.S. I'd love to debate this with any rabid MS fanatics who think Windows is the greatest thing since sliced bread, but it might be too easy. Bring it on.
---
pb Reply or e-mail; don't vaguely moderate.
I'll help you to understand.
Omitting white space really does speed it up; that's because the first thing the Perl interpreter has to do is read in the file, and if the file is shorter, it has to read less. If you *must* use some spaces, then pad it at the end and align it to a 4096 byte boundary (or at least 512 bytes). Also, when the code is tokenized, you don't have to ignore as much whitespace, or allocate as much memory as a buffer. All of these are improvements.
Enforced scope is fine, if you only need a variable in that scope; that's what my is for. But why always deallocate and allocate off the stack when you can have a few permanent, reusable memory locations? This is especially true for replacing extra loop counters, or getting rid of variable allocation in tight loops or small subroutines. Why be so wasteful?
Also, $m is a variable, and probably a mnemonic as well. $m2 is another $m distinct from the first. $mt2 is probably a temp variable, maybe for $m2. See the simple yet concise variable naming scheme at work?
So I suppose this self-taught programmer also considered comments and documentation to be a waste of disk space? I'm sorry, I've done that before. Managed to delete a lot of silly code, too...
---
pb Reply or e-mail; don't vaguely moderate.
They're just as far behind. Use this formula:
Apple_Max_Mhz*2 ~= x86_Max_Mhz
...sounds about right to me.
Never mind that Joe Average generally doesn't need nearly that much power for all the things he really needs to do. Any home computer sold in the past 15 years can easily do word processing and spreadsheets, even a Pentium 133 plays mp3's with some cycles left to spare, and unless you're still using that 386, your modem is the bottleneck in browsing the web, not your processor, no matter what Intel tells you...
---
pb Reply or e-mail; don't vaguely moderate.
Fade in:
D-VHS Tape looks over at the large server computer, and says: "RAID? Oh NO!!!"
D-VHS tape is quickly recorded and then explodes...
RAID. Kills tapes dead, where they hide.
---
pb Reply or e-mail; don't vaguely moderate.
Use it for automated, batched transfers. Use it for mail and newsgroups. Maybe use it for ftping large files.
But for god's sake, don't use it to browse the web, unless you plan to use your web browser like an Off-Line Reader...
---
pb Reply or e-mail; don't vaguely moderate.
Troll stories at troll times; what will they think of next?
Man, I'm only reading slashdot at night if I can help it now; the WTO will never restrict my pancakes, right, ninjas???
---
pb Reply or e-mail; don't vaguely moderate.
First, I'd like to know just how much "Open Source" code was lifted, and from where.
If it's from X, well, that's cool (BSD-style). If it's from the Linux Kernel, that would probably not be cool (likely just GPLed). I guess we'll see when it comes out, but the reference to 'strict licensing terms' makes me a little leery.
Also, could they pick a new name before it comes out, please? Between MIT's Project Athena, and AtheOS, I'm confused already.
Until then, that's the most kick-ass version of twm I've ever seen, and at the moment it looks like they went through a lot of work to implement essentially a new version of Enlightenment on top of Linux; until they expand their platform support a bit I won't be that impressed.
---
pb Reply or e-mail; don't vaguely moderate.
As long as it can hold at least a GB or two, that's more than enough for me. I don't know if I'd want to pay ~$400 for it, though; I'd definitely pay $200.
As to the interface, I'm sure that'll get reverse-engineered soon enough, but it'd be much nicer if it didn't have to; there's no reason to develop a proprietary protocol for this. Heck, what's wrong with ftp?
---
pb Reply or e-mail; don't vaguely moderate.
Wow. Ten ideas that made it big for a short period of time, and then got superceded by other new ideas. Big deal.
They got outcompeted; they served their time, and now they're relegated to their technological niches. The implementation is outmoded, but the idea lives on. That's how unnatural selection works; it's technological Darwinism.
---
pb Reply or e-mail; don't vaguely moderate.
No, winamp is a proprietary API, and they're both reinventing the wheel. All you have to do is statically link GTK, and there's no difference from the perspective of an outside user.
:)
What you'd need to do is create a GTK wrapper for Win32; then you could thunk through all the calls you need, and port all the GTK stuff to (mostly) native Windows.
In fact, I'd want wrappers for everything to a target API, personally, so I could port everything, and make it all themeable. But it'd be a lot of work...
Also, you don't need efficiency in an IM client; otherwise, people would never write them in Java and Tcl/Tk.
---
pb Reply or e-mail; don't vaguely moderate.
I suppose you don't use winamp, then?
:)
The "Standard GUI" argument doesn't mean much to me, and it means even less when you don't have to compile it yourself, and you don't know what gets installed on your system--like your average Windows user.
---
pb Reply or e-mail; don't vaguely moderate.
Hey, thanks! If I had found that earlier, it would have saved me some time. :)
So basically, we still need to standardize the 'IMX' protocol; that's the one thing that document explicitly doesn't cover. And it looks like the only perspective on what to support comes from RFCs 2778 and 2779...
---
pb Reply or e-mail; don't vaguely moderate.
Well, I'm not quite sure why the FCC thinks they'd know about this area, but I'm pretty sure they're just overseeing the merger, and not drafting the standard. It's a little creepy, but not as creepy as letting The Secret Service handle Computer Crime.
:)
I wish E-mail programs were interoperable; as it is, I see a lot of MIME headers that break elm. But usually that's just spam; only occasionally is it from real people (users of OutLook) that don't know how to send *text*...
These guys wrote RFC2778 and RFC2779; it seems to be designed from an "agent" perspective. I suppose that's the new, hot trend nowadays, but it seems a little heavyweight for just a chat client. However, they're working on it and I'm not, so I suppose I can't complain.
Does anyone know about any other RFCs related to this?
---
pb Reply or e-mail; don't vaguely moderate.
"perhaps I am some christian missionary in your fantasies"?
Never hack AOLiza to post to slashdot; you'd get too many biters.
"First Post!"
"Does it please you to get First Post?"
"I 0wn j00!!!"
"Interesting, please continue."
---
pb Reply or e-mail; don't vaguely moderate.
Have you tried The GIMP (under Win32) lately? GTK for Windows seems pretty decent.
Of course, a lot of the Windows port stuff is pretty beta-ish. As in, all the basic command-line stuff seems to work, and maybe you could compile X applications under Windows with cygwin, but the port of XFree86 itself is definitely alpha.
I'd love to see more skins for Whistler, since there are only two at the moment: one looks just like Win95/98, and the other one sucks. Hard.
---
pb Reply or e-mail; don't vaguely moderate.
I agree; I want that too.
Until then, I'm using EveryBuddy. In fact, it looks like they have a new release out...
It isn't perfect; it's more like sox. It's the swiss-army knife of IM clients.
---
pb Reply or e-mail; don't vaguely moderate.
Actually, unlike the misleading /. blurb, this would involve the creation of an "industry standard" that AOL-TW would have to adopt.
Sounds good to me. I mean, really, how many stupid datagram headers can you have anyhow? I implemented tftp recently, and that wasn't hard at all.
I say we do this the old-fashioned way. Draft a standard, and write an RFC. We shouldn't need more than 5-7 actual commands anyhow.
---
pb Reply or e-mail; don't vaguely moderate.
Dr. Livingston, what's that?
I believe it's a very rare species of post.
I don't think I've ever seen it before.
I used to see it every so often, in the past.
It's a first post! Therefore, it should be modded down.
No, no my dear, it's an intelligent first post.
An intelligent first post?
I told you it was rare. I haven't seen actual posting content in a long time, let alone an intelligent first post.
I say!
Indeed.
---
pb Reply or e-mail; don't vaguely moderate.
I don't think it's *that* detailed, guys.
Here's one of the early "meter" images.
Sure, you can see the road, and big buildings, but you can't really identify a person...
---
pb Reply or e-mail; don't vaguely moderate.
Well, gosh, someone tell them that!
I was pretty sure a Trident TGUI9680 was common when I had it, but it was supported in Grayscale.
I think it used the standard SVGA Server....
---
pb Reply or e-mail; don't vaguely moderate.
That's true; but if they don't tell me about it, I won't know to be upset; ignorance is bliss, and all. :)
Hey, if I'm done working on it, and other people aren't, so be it. That's when you appoint a maintainer and do other stuff. But at least I'll have the ability to browse through it later at my leisure, and see what's new, and be proud of what I started....
---
pb Reply or e-mail; don't vaguely moderate.
Well, either you need that, or you need a lot of man-hours to support as much stuff as Linux does, and a whole lot of information that certain hardware companies often don't give you...
In any case, it couldn't hurt. I mentioned this because BeOS didn't support my old video card...
---
pb Reply or e-mail; don't vaguely moderate.
I think the question is, what if everyone could share code? The BSD License makes it so that everyone can have the code; the GPL makes it so that everyone has to share.
And I think that Linux would get another journaling filesystem, and maybe some threaded C libraries, and that would kick ass. And BeOS would get a whole lot of drivers, which would also be very cool. And maybe they could eventually merge together.
Although it'd be more unlikely for Linux and "Linux projects" (which often tend to compile on other Unixes as well) to switch to *BSD, I think what you'd see is a lot more code sharing, but then you'd have corporations involved as well. That would be the big difference.
I don't think it's going to actually happen, mind you, but being able to share code is definitely a good thing, and also the point of free licenses. It's a shame that these two are incompatible, but they also have different goals.
I'm not a BSD user because developments like MacOS X make me uncomfortable. It's an ideological difference. I don't like the idea of someone modifying my code and not showing me what they did. I'd like to know, in the same way that a playwright would like to know if you changed the Third Act on him while producing his play, and then made money on it, and told everyone else that it was "your play" now, based on their play, but only your company had rights to your version...
---
pb Reply or e-mail; don't vaguely moderate.
1) Operating Systems provide services to applications.
2) Inferno is an OS
3) Limbo apps run on Inferno
If, indeed, Limbo apps need services from Inferno to run, and the Browser Plug-in can do this as well, then it would follow that....
4) The web browser plug-in is an OS for the same reasons that Inferno is.
Apparently those required services are called "Dis". I catch the reference, but it's been a while since I read up on Inferno.
In any case, it's definitely blurring the line for what an OS is and isn't. It's pretty far away from the hardware, in any case.
But wasn't that what people were predicting? Wasn't that why Microsoft was afraid of Netscape, and then Java? "The browser is the OS"?
That's right, folks. It's not just emacs anymore.
---
pb Reply or e-mail; don't vaguely moderate.
(screenshot is here)
Tetris I can take or leave, but I love Reversi.
However, I remember an Othello game for the Apple II; I think it moved randomly. Therefore, I could almost always win, even back then. So I don't see the advantage.
Try again; you won't be able to seduce me to your wicked ways!
---
pb Reply or e-mail; don't vaguely moderate.