Why couldn't they have just picked up the "real" Lara Croft for the movie adaptation? I can't imagine a video-game-turned-movie is going to have much in the way of acting requirements, anyway.
True, but you still gotta have professional acting experience. That cuts it down to a small subset of those with good looks };-)
Incidentally, has anyone here seen the InciteGames poster of LC for TR: The Last Revelation? It's this almost life-size poster of a non-CG Lara. She looks all right, although the similarity to the canonical CG model is a bit of a stretch.
(Oh, and for those curious, she actually has (*gasp!*) realistically sized breasts! No helium hooters here, folks!)
The most amusing thing about that poster is the name of the model, mentioned way at the bottom-left corner: Lara Weller.
Virtual boot floppy possible?
on
BeOS For Linux!
·
· Score: 2
The image file / boot floppy setup is really nice if you don't want to go through the ordeal of repartitioning, but having to pull out a floppy everytime you want to start up BeOS is kind of annoying too.
Is there a way to set up LILO so that it can read the floppy image off an ext2 partition, and "boot" it? So that no floppy drive is ever involved? That would be very handy.
I grabbed it on the 28th too, and the image/boot disk setup worked like a charm. Just a shame that my Ensoniq SoundScape (AD1848 chipset) is silent under the BeOS-- and from looking at the drivers sites, it's going to stay that way:-(
Y'all don't forget to download BeOS5-DevTools.zip, y'hear? An OS isn't an OS when it doesn't have [a-z]*cc somewhere!
What I really like about FreeBe (aside from the merits of BeOS as a media operating system) is that it's going to be an awesome platform for acid-testing the cross-platformness of software. The filesystem layout has only a hint of UNIX to it, and of course the OS facilities are very different from UNIX-like systems (standard POSIX being the only constant). A lot of software packages out there that build on Linux/UNIX are not going to build on BeOS, and in a lot of cases, it's going to be because of silly little UNIX-centric assumptions in the configure script, or the code, or wherever. Here, now, is an opportunity to get rid of those!
Methinks a lot of maintainers are going to be getting patches to that effect, in these coming months;-) I know I'm going to make sure my stuff can build on Be.
What sucks about the OSS driver is its lack of MIDI support (okay, you *can* do MIDI, but you can't adjust the volume and it plays EXTREMELY LOUD)
Depends what program you're using...
No, it's an actual limitation of the driver. I e-mailed the OSS guy (Hannu something) a while ago about this, and he said that the driver doesn't do it. That the commercial OSS one did:-P
I didn't know ALSA had similar bugs . . . but those are almost certainly getting looked at. The OSS drivers, I'm pretty sure no one is hacking on anymore.
Incidentally, something I've been wondering . . . ALSA is very nice, from all I've heard. Good architecture, and many nice features.
Only thing is, I have an Ensoniq SoundScape, which is only supported by the OSS drivers in the stock kernel.
Has the ALSA folks been eyeing the OSS drivers, to "absorb" them into ALSA? Would retooling the older drivers be too nontrivial? Are they focusing their efforts on newer hardware? What's the situation?
What sucks about the OSS driver is its lack of MIDI support (okay, you *can* do MIDI, but you can't adjust the volume and it plays EXTREMELY LOUD) and the annoying "pop" it makes whenever it starts playing digital audio. ALSA fixes both these problems, and goes way beyond.
Yah! An open-source voice-recogition SDK would be too cool for words. I don't think L&H would go for that, however. Their product line seems focused mainly on shrink-wrap Windows applications. No OSS vibes there:-(
Alternately, there's IBM's ViaVoice SDK, but it's closed-source, and I think it's still in beta. There's also CVoiceControl, but it doesn't look like a very sophisticated implementation. (Then again, I haven't tried either of these). There's still a need for a free-as-speech, smooth-as-glass voice recognition library.
ObOnTopic: Speech control is PERFECT for a PDA-type device. It gives you almost all the flexibility of a CLI, without the overhead of a keyboard. But methinks it'll be tricky to get it running smooth enough so I don't have to repeat commands, or otherwise utter them like two inches from the microphone:->
It shouldn't be that hard. The car would probably slow down to about 60 km/h, and release its "grip" on the wheel over an interval of a few seconds. The dangerous thing to be on guard for (which I imagine is what you had in mind) is if the wheel controller is applying a torque at the time of release. A momentary snap of the wheel, at highway speeds, can indeed cause an accident. Releasing the wheel gradually should take care of that.
In any case, if the car's on a straightway, it shouldn't be applying torque to the wheel anyway. It's only an issue if you're on a turn, or if your steering is waaaay out of alignment:-]
Things like major obstacles entering the road (e.g. deer, or maybe a swerving car) and such would be tricky to handle. At least they're rare circumstances. You might have the car sound an alarm, to let the driver take the wheel and do what it necessary.
Or possibly, a rear-facing distance sensor could detect how far back is the car behind you, and if the space is wide enough, the system could then safely slam on the brakes. (Passengers had better be using their seat belts!)
Traffic jams, slowdowns, etc. would need no special logic to handle. As long as the car is aware of where the next one in front of it is, all it needs to do is drive at the highest speed that keeps it a safe distance away, without exceeding the limit. So if it ran into a traffic snarl, it would (in theory) slow down automatically.
I wonder if they're aiming this thing to be capable of driving around a city scene (e.g. Manhattan). A very hard problem, no doubt.
But heck, likely the benefit of most value to the majority of drivers out there would be automatic highway driving. And that wouldn't be nearly as difficult to implement. All you'd really need are two electric eyes to watch the road lines (keeping the car centered in its lane), and a distance sensor to keep the car a safe distance from the one in front. Making it safe to, say, read a book while you're cruising along.
Such a system has much room for refinement, of course (automatic passing?) but it would make highway driving less of a bore/chore, and would likely reduce a great number of accidents caused by falling asleep at the wheel.
Right, right, you're right. I forgot about IE on Mac.
A funny thing: I've heard that the Mac version is actually a lot more standards-compliant than the Windows one. It kind of makes you wonder if Microsoft took into account the significant proportion of web developers that use Macs.
It also suggests that the IE codebases for the two systems are different. In the way of non-Windows versions, what I always think of is the horrible Solaris port. Which was more of a *port*, in the usual sense-- they practically re-implemented all of Win32 just to get the thing to run. And, sure enough, it ended up running like a total pig.
That, in combination with the whole NT/Alpha 32-bit-system-on-a-64-bit-chip mess, have pretty much convinced me that Microsoft can't write cross-platform software to save its life. (IE and Office have to be near-complete rewrites. Hey, they can afford it!)
If this browser is not at least as fast as IE5 (or faster), they shouldn't bother.
I beg your pardon! IE is Windows-only, which makes it useless for non-Windows users, and embedded systems.
As for speed, remember that Mozilla still has a lot of debugging code left to trim out. I can't say whether IE may be faster than the final release; that may very well be the case. But I'd rather take a well-designed, 100% standards-compliant, and still-blazingly-fast Mozilla, over a single-platform, non-source-available, mostly-standards-compliant-but-with-some-exception s browser.
(Technically, the difference is similar to the correctness-before-speed Apache vs. the speed-at-all-costs IIS. But here, there's no ease-of-use issue to consider;-)
What's especially nice about Mozilla is that it will likely become another Linux. Where you have this open code base, that anyone can get their hands into and improve. So if anyone out there is unhappy with Mozilla's performance, and they have the necessary technical skill, they can do something about it. Given the large number of people to which a browser is a useful application, there are many such potential contributors around-- both individuals and commercial interests. AOL is only one of many.
Just like everyone and their dog is working right now to make Linux into the be-all end-all of operating systems (high-end SMP, XFS, S/390 ad infinitum), so will it probably happen with Mozilla. So, while the first non-beta release may come up short of IE (although it won't be by much), future releases are going to eclipse it completely.
IE is pretty much confined to where it is right now. Mozilla is going to be everywhere else.
C has its shortcomings, but don't forget why hackers like it so much: minimalism. The language has a very brief spec, it does virtually nothing behind your back, and the system standard library gives you basic functionality, no more. Because of this, there is an elegance to C code (particularly in writing it!) that you simply don't get with many more modern languages.
That's my opinion, but I have to agree the lack of language-level support for things like classes, inheritance, fine-grained scoping, etc. is bothersome. Not enough to make me want to move to C++, but enough to make me wish some language junkies in the free-software community would get together, and create a derivative of C that addresses all those problems. A language that can do OO gracefully, without any run-time magic (unlike ObjC), that has a small specification (unlike C++), and a reasonably limited system library (unlike Java).
If that were to come about, in conjuction with a small $LANG-to-C translator program that could be put into tarballs, I think the architects of Gnome would be willing to give it a try. *I* certainly would . . . .
I'm wondering... what do the C extensions look like? C++ has the STL vector types (also a matrix type, right?) but C just has arrays of int/float/double. Is there an API reference anywhere? Is an API even involved? What would AltiVec-enabled C code look like?
Heh. What you want is one of the old-school IBM PS/n keyboards. No OS-specific keys, tactile feedback you can feel and *hear*, and a built-like-a-tank construction you just don't see in computer hardware anymore. This thing weighs like ten pounds. It eats other keyboards for breakfast };-)
And as for the Ctrl key thing, hey, nothing a couple of self-adhesive stickers and xmodmap can't fix . . .
Incidentally, something I've wondered about for a long time now . . . why is it called Skunkware?
(Don't get me wrong; I absolutely LOVE the name ^_~ I'm just not sure I see how they happened to connect "skunk" and "open source software" to make it)
I did exactly that a while ago, after seeing it suggested here. In the case of Linux, it would of course involve the/etc/hosts file.
For some reason, however, whenever I hit a site with a DoubleClick banner (ad.doubleclick.net is included in the kill list) the browser immediately forwards to a 404 Not Found page, served up by the webserver on my machine. I hit Back, and immediately it returns to the 404.
And this sometimes happens with Slashdot, of all places! Anyone know why? Ideas for a fix? (Junkbuster is out, only 64MB RAM here:-(
And this is only in addition to the multiple-architecture issue, right? An XFree4.0 module for i386 won't work on PPC, won't it?
What I often wonder is why hardware manufacturers can't just streamline the damn hardware interface so that the drivers don't tell what's going on inside! I talked with an Nvidia rep a while ago at a career fair, and he dropped hints that that was where they were headed-- and that future chipset drivers would of course have source-- but it seems they're still not taking the need for source-available drivers into their hardware design.
I'd at least hope they eventually release the driver source, once the GeForce/Quatro is old stuff, although the fact that they aren't using the DRI means a lot of work still remains to be done-- and since drivers like these are supposedly not easy to hack on, and their value then will be much less than it is now, it's likely we may never see a properly designed, source-available driver for our Nvidia hardware. Grrrr!
SGML would be better. Librarians invented SGML for exactly such purposes (long-term data storage). It allows you to encode all sorts of things, like hyperlinks, proper footnotes, typesetting/formatting information, etc.
IMHO, I think a lightweight SGML variant would be ideal for PG. From that, you could use freeware tools (like Jade) to generate TXT, HTML, DVI, PDF files as necessary, with hyperlinks and/or beautiful TeX-like typesetting as the format allows. And the source language would be stable enough to not be completely irrelevant 100+ years down the line. (which, btw, I think will become the case with HTML)
Of course, it goes almost without saying that even better than designing an office suite with an improved UI is something better than an office suite, period. I only lament that, if a radical new system not unlike Cyberdog were to be developed within the bazaar of the free-software world, it would take years-- perhaps decades-- for it to reach mainstream use. Hence the dilemma.
Regarding Tog or Nielson's help: All I intended to suggest in the way of assistance was minimal commentary, probably critiques on proposed interface designs. Of course it's assumed that whoever is doing the bulk of such designs will be well read up on the literature of the field. (So that way, the UI gurus can't just say, "All this is covered in my book . ..";-)
It's all a matter of perspective. Just imagine: the coders writing these new interfaces are probably going to be using Emacs. And of course it works fine for them, but . . . you can see how there's a wee bit of a disconnect there as far as UI design paradigms are concerned. And that's why some sage words of advice from someone outside the coding trenches (and that covers most of "the community") would be invaluable.
Additionally, the Cyberdog tale really pointed out: it would be very helpful to the development of Gnome/KDE for the top architects to actually see some of the state-of-the-art technologies out there. I mean, half the features in Gnumeric are there because Miguel happened to have a copy of Windows and Excel. If he were to have a Macintosh running Cyberdog, or a PC running OS/2, or whatever, is there any reason to believe some of the good ideas in those systems would not find their way into Gnome?
Yah, this is something that's bothered me for a while, just at the philosophical level. When you're talking about 'office'-suite design, and how you create the interface, you have these three very-difficult-to-reconcile points to consider:
The UI of the dominant office suite leaves a lot to be desired. Way too many buttons, way WAY too many menu items . . . suffice it to say, it does the job, but doesn't win any usability awards. Gnome/KDE could, in time, design a better system if they really put their hearts into it. Something even Tog or J. Nielson would approve of, or at least not totally rip to shreds in one of their columns. (Maybe, if we asked real nicely, they could help out . ..)
Like, 95% of the world's population have never used a desktop environment. (Random, probably not even accurate statistic I saw somewhere, but it's enough to say there's a LOOOOOOOT of people in this world who have never used MSOffice, and whose first office suite will probably be Gnome's or KDE's)
Of the 5% (or whatever) of people that have used an office suite before, that office suite is MS Office, and if any other office suite is to gain market acceptance, money to back it, and a hope of eliminating the dependency on Microsoft, it will have to walk, talk, and dance like MSOffice-- or else "retraining costs" will keep the encumbant entrenched till the end of time.
It's a really bad fix to be in. It's kind of like asking yourself, at what point in the last century did it become too late to replace the now-ubiquitous and not-very-wrist-friendly QWERTY keyboard layout with a better one (Dvorak or otherwise?)
Perhaps the answer might be to develop two completely different UI designs, one chosen at compile time. One for MSOffice veterans, and one for those who want something better. I really think it would be a shame to make people who have never used MSOffice basically learn the MSOffice interface (or a sufficiently MSOffice-like interface) to get up to speed on their new cutting-edge free-software office suite.
Just wait until SGI starts selling mid-grade Linux workstations. They already have an X server for Nvidia hardware (in-house only for now, but not for long) that is said to blow Octanes out of the water. (Holy hardware T&L, Batman! I believe it!)
No timetables have been released, but I'd expect they'd have the line of workstations and the Oh-My-God-That's-Fast Nvidia drivers out by sometime this summer. At that rate, we can probably expect a port of Studio/Maya announced-- if not completed-- by the end of this year.
Indeed, with Linux, the question is never if, but when };-)
Batteries are usually designed with the possibility of recycling. That's why used car batteries (the regular kind) don't present an environmental hazard in disposal; auto garages already know what to do with them.
As for cars blowing up, remember, real life isn't like you see in the movies. It doesn't happen that often! Nowhere near enough to present an environmental issue.
The real environmental hit of electric cars are the power plants, which have to work harder to feed them when they're plugged in. So if your city is powered by a coal-fired plant, and everyone gets an electric car, the air ain't getting any cleaner.
But the advantage, then, is that-- in programmer's parlance-- the power source has been abstracted away from the car engine. So you can change the power source's implementation (say, from coal energy to wind energy) without breaking the rest of the system. Unlike the internal combustion engine, where the power source (gasoline) and application logic (engine) are so closely intertwined that it's impossible to port to any other architecture.
Methinks, however, even better than electric power for transportation is hydrogen power. You don't need super-high-tech batteries to power it, just armored fuel tanks, and an efficient way of producing the stuff. The exhaust products are (theoretically) just CO2+H20. (IIRC, however, since some nitrous oxides inevitably get into the air intake, you do get some icky exhaust hydrocarbons too, but nothing overwhelming)
you want to talk to an api that understands things like 'here is the geometry objecttree, here are the sound objects'. And all sound properties/data are stored with these soundobjects
With respect to OpenGL, that's what you use a scene graph for (e.g. Inventor). OpenAL, like OpenGL, is intended to be a low-level (yet platform-independent) interface to the hardware. What you want is something higher-level.
Also, remember that OO is not the be-all end-all of programming approaches. OpenAL would be a lot less flexible and useful if it were implemented that way (as, say, a set of fully-OO C++ classes).
I read that there is an API for reading CD audio and playing it (how many more CD Players do we need:-) ?). Does OpenAL include support for mp3, MSAudio, Liquid Audio, Barry's Mega Audio, etc, or include hooks for these to be implemented, perhaps by third party software such as XMMS? Or am I getting a bit to specific...
Eep! You don't want all that junk in the API. That'd be akin to OpenGL having glSomething calls to decode GIF images, PNG's, JPG's, 3D file formats, etc.
What make the approach they're taking really nice is that the API is staying clean. They're not trying to throw everything under the sun into the library-- they're keeping its scope razor-sharp, and leaving application-specific concerns like those to other libraries.
That way, you don't run into library overlap, which is incredibly bothersome if you're trying to write elegant code. (E.g. when you're using GLib, do you go with printf(), or g_print()? I hate having to decide things like that)
Kudos to Loki for following the footsteps of one of the most beautiful API's in existence, and for committing to keep it that way. I just know I'm going to write an OpenGL+OpenAL program someday, and I'm going to enjoy it immensely }:-)
Slashdot Mirror
Why couldn't they have just picked up the "real" Lara Croft for the movie adaptation? I can't imagine a video-game-turned-movie is going to have much in the way of acting requirements, anyway.
True, but you still gotta have professional acting experience. That cuts it down to a small subset of those with good looks };-)
Incidentally, has anyone here seen the InciteGames poster of LC for TR: The Last Revelation? It's this almost life-size poster of a non-CG Lara. She looks all right, although the similarity to the canonical CG model is a bit of a stretch.
(Oh, and for those curious, she actually has (*gasp!*) realistically sized breasts! No helium hooters here, folks!)
The most amusing thing about that poster is the name of the model, mentioned way at the bottom-left corner: Lara Weller.
The image file / boot floppy setup is really nice if you don't want to go through the ordeal of repartitioning, but having to pull out a floppy everytime you want to start up BeOS is kind of annoying too.
Is there a way to set up LILO so that it can read the floppy image off an ext2 partition, and "boot" it? So that no floppy drive is ever involved? That would be very handy.
I grabbed it on the 28th too, and the image/boot disk setup worked like a charm. Just a shame that my Ensoniq SoundScape (AD1848 chipset) is silent under the BeOS-- and from looking at the drivers sites, it's going to stay that way :-(
;-) I know I'm going to make sure my stuff can build on Be.
Y'all don't forget to download BeOS5-DevTools.zip, y'hear? An OS isn't an OS when it doesn't have [a-z]*cc somewhere!
What I really like about FreeBe (aside from the merits of BeOS as a media operating system) is that it's going to be an awesome platform for acid-testing the cross-platformness of software. The filesystem layout has only a hint of UNIX to it, and of course the OS facilities are very different from UNIX-like systems (standard POSIX being the only constant). A lot of software packages out there that build on Linux/UNIX are not going to build on BeOS, and in a lot of cases, it's going to be because of silly little UNIX-centric assumptions in the configure script, or the code, or wherever. Here, now, is an opportunity to get rid of those!
Methinks a lot of maintainers are going to be getting patches to that effect, in these coming months
What sucks about the OSS driver is its lack of MIDI support (okay, you *can* do MIDI, but you can't adjust the volume and it plays EXTREMELY LOUD)
:-P
Depends what program you're using...
No, it's an actual limitation of the driver. I e-mailed the OSS guy (Hannu something) a while ago about this, and he said that the driver doesn't do it. That the commercial OSS one did
I didn't know ALSA had similar bugs . . . but those are almost certainly getting looked at. The OSS drivers, I'm pretty sure no one is hacking on anymore.
Incidentally, something I've been wondering . . . ALSA is very nice, from all I've heard. Good architecture, and many nice features.
Only thing is, I have an Ensoniq SoundScape, which is only supported by the OSS drivers in the stock kernel.
Has the ALSA folks been eyeing the OSS drivers, to "absorb" them into ALSA? Would retooling the older drivers be too nontrivial? Are they focusing their efforts on newer hardware? What's the situation?
What sucks about the OSS driver is its lack of MIDI support (okay, you *can* do MIDI, but you can't adjust the volume and it plays EXTREMELY LOUD) and the annoying "pop" it makes whenever it starts playing digital audio. ALSA fixes both these problems, and goes way beyond.
Yah! An open-source voice-recogition SDK would be too cool for words. I don't think L&H would go for that, however. Their product line seems focused mainly on shrink-wrap Windows applications. No OSS vibes there :-(
:->
Alternately, there's IBM's ViaVoice SDK, but it's closed-source, and I think it's still in beta. There's also CVoiceControl, but it doesn't look like a very sophisticated implementation. (Then again, I haven't tried either of these). There's still a need for a free-as-speech, smooth-as-glass voice recognition library.
ObOnTopic: Speech control is PERFECT for a PDA-type device. It gives you almost all the flexibility of a CLI, without the overhead of a keyboard. But methinks it'll be tricky to get it running smooth enough so I don't have to repeat commands, or otherwise utter them like two inches from the microphone
It shouldn't be that hard. The car would probably slow down to about 60 km/h, and release its "grip" on the wheel over an interval of a few seconds. The dangerous thing to be on guard for (which I imagine is what you had in mind) is if the wheel controller is applying a torque at the time of release. A momentary snap of the wheel, at highway speeds, can indeed cause an accident. Releasing the wheel gradually should take care of that.
:-]
In any case, if the car's on a straightway, it shouldn't be applying torque to the wheel anyway. It's only an issue if you're on a turn, or if your steering is waaaay out of alignment
Things like major obstacles entering the road (e.g. deer, or maybe a swerving car) and such would be tricky to handle. At least they're rare circumstances. You might have the car sound an alarm, to let the driver take the wheel and do what it necessary.
Or possibly, a rear-facing distance sensor could detect how far back is the car behind you, and if the space is wide enough, the system could then safely slam on the brakes. (Passengers had better be using their seat belts!)
Traffic jams, slowdowns, etc. would need no special logic to handle. As long as the car is aware of where the next one in front of it is, all it needs to do is drive at the highest speed that keeps it a safe distance away, without exceeding the limit. So if it ran into a traffic snarl, it would (in theory) slow down automatically.
I wonder if they're aiming this thing to be capable of driving around a city scene (e.g. Manhattan). A very hard problem, no doubt.
But heck, likely the benefit of most value to the majority of drivers out there would be automatic highway driving. And that wouldn't be nearly as difficult to implement. All you'd really need are two electric eyes to watch the road lines (keeping the car centered in its lane), and a distance sensor to keep the car a safe distance from the one in front. Making it safe to, say, read a book while you're cruising along.
Such a system has much room for refinement, of course (automatic passing?) but it would make highway driving less of a bore/chore, and would likely reduce a great number of accidents caused by falling asleep at the wheel.
Right, right, you're right. I forgot about IE on Mac.
A funny thing: I've heard that the Mac version is actually a lot more standards-compliant than the Windows one. It kind of makes you wonder if Microsoft took into account the significant proportion of web developers that use Macs.
It also suggests that the IE codebases for the two systems are different. In the way of non-Windows versions, what I always think of is the horrible Solaris port. Which was more of a *port*, in the usual sense-- they practically re-implemented all of Win32 just to get the thing to run. And, sure enough, it ended up running like a total pig.
That, in combination with the whole NT/Alpha 32-bit-system-on-a-64-bit-chip mess, have pretty much convinced me that Microsoft can't write cross-platform software to save its life. (IE and Office have to be near-complete rewrites. Hey, they can afford it!)
If this browser is not at least as fast as IE5 (or faster), they shouldn't bother.
n s browser.
;-)
I beg your pardon! IE is Windows-only, which makes it useless for non-Windows users, and embedded systems.
As for speed, remember that Mozilla still has a lot of debugging code left to trim out. I can't say whether IE may be faster than the final release; that may very well be the case. But I'd rather take a well-designed, 100% standards-compliant, and still-blazingly-fast Mozilla, over a single-platform, non-source-available, mostly-standards-compliant-but-with-some-exceptio
(Technically, the difference is similar to the correctness-before-speed Apache vs. the speed-at-all-costs IIS. But here, there's no ease-of-use issue to consider
What's especially nice about Mozilla is that it will likely become another Linux. Where you have this open code base, that anyone can get their hands into and improve. So if anyone out there is unhappy with Mozilla's performance, and they have the necessary technical skill, they can do something about it. Given the large number of people to which a browser is a useful application, there are many such potential contributors around-- both individuals and commercial interests. AOL is only one of many.
Just like everyone and their dog is working right now to make Linux into the be-all end-all of operating systems (high-end SMP, XFS, S/390 ad infinitum), so will it probably happen with Mozilla. So, while the first non-beta release may come up short of IE (although it won't be by much), future releases are going to eclipse it completely.
IE is pretty much confined to where it is right now. Mozilla is going to be everywhere else.
C has its shortcomings, but don't forget why hackers like it so much: minimalism. The language has a very brief spec, it does virtually nothing behind your back, and the system standard library gives you basic functionality, no more. Because of this, there is an elegance to C code (particularly in writing it!) that you simply don't get with many more modern languages.
That's my opinion, but I have to agree the lack of language-level support for things like classes, inheritance, fine-grained scoping, etc. is bothersome. Not enough to make me want to move to C++, but enough to make me wish some language junkies in the free-software community would get together, and create a derivative of C that addresses all those problems. A language that can do OO gracefully, without any run-time magic (unlike ObjC), that has a small specification (unlike C++), and a reasonably limited system library (unlike Java).
If that were to come about, in conjuction with a small $LANG-to-C translator program that could be put into tarballs, I think the architects of Gnome would be willing to give it a try. *I* certainly would . . . .
Most cool!! Linux has Supercomputer Power now!!
(tongue-in-cheek, yah, but cool nonetheless)
I'm wondering... what do the C extensions look like? C++ has the STL vector types (also a matrix type, right?) but C just has arrays of int/float/double. Is there an API reference anywhere? Is an API even involved? What would AltiVec-enabled C code look like?
Heh. What you want is one of the old-school IBM PS/n keyboards. No OS-specific keys, tactile feedback you can feel and *hear*, and a built-like-a-tank construction you just don't see in computer hardware anymore. This thing weighs like ten pounds. It eats other keyboards for breakfast };-)
And as for the Ctrl key thing, hey, nothing a couple of self-adhesive stickers and xmodmap can't fix . . .
Incidentally, something I've wondered about for a long time now . . . why is it called Skunkware?
(Don't get me wrong; I absolutely LOVE the name ^_~ I'm just not sure I see how they happened to connect "skunk" and "open source software" to make it)
I did exactly that a while ago, after seeing it suggested here. In the case of Linux, it would of course involve the /etc/hosts file.
:-(
For some reason, however, whenever I hit a site with a DoubleClick banner (ad.doubleclick.net is included in the kill list) the browser immediately forwards to a 404 Not Found page, served up by the webserver on my machine. I hit Back, and immediately it returns to the 404.
And this sometimes happens with Slashdot, of all places! Anyone know why? Ideas for a fix? (Junkbuster is out, only 64MB RAM here
And this is only in addition to the multiple-architecture issue, right? An XFree4.0 module for i386 won't work on PPC, won't it?
What I often wonder is why hardware manufacturers can't just streamline the damn hardware interface so that the drivers don't tell what's going on inside! I talked with an Nvidia rep a while ago at a career fair, and he dropped hints that that was where they were headed-- and that future chipset drivers would of course have source-- but it seems they're still not taking the need for source-available drivers into their hardware design.
I'd at least hope they eventually release the driver source, once the GeForce/Quatro is old stuff, although the fact that they aren't using the DRI means a lot of work still remains to be done-- and since drivers like these are supposedly not easy to hack on, and their value then will be much less than it is now, it's likely we may never see a properly designed, source-available driver for our Nvidia hardware. Grrrr!
SGML would be better. Librarians invented SGML for exactly such purposes (long-term data storage). It allows you to encode all sorts of things, like hyperlinks, proper footnotes, typesetting/formatting information, etc.
IMHO, I think a lightweight SGML variant would be ideal for PG. From that, you could use freeware tools (like Jade) to generate TXT, HTML, DVI, PDF files as necessary, with hyperlinks and/or beautiful TeX-like typesetting as the format allows. And the source language would be stable enough to not be completely irrelevant 100+ years down the line. (which, btw, I think will become the case with HTML)
Of course, it goes almost without saying that even better than designing an office suite with an improved UI is something better than an office suite, period. I only lament that, if a radical new system not unlike Cyberdog were to be developed within the bazaar of the free-software world, it would take years-- perhaps decades-- for it to reach mainstream use. Hence the dilemma.
." ;-)
Regarding Tog or Nielson's help: All I intended to suggest in the way of assistance was minimal commentary, probably critiques on proposed interface designs. Of course it's assumed that whoever is doing the bulk of such designs will be well read up on the literature of the field. (So that way, the UI gurus can't just say, "All this is covered in my book . .
It's all a matter of perspective. Just imagine: the coders writing these new interfaces are probably going to be using Emacs. And of course it works fine for them, but . . . you can see how there's a wee bit of a disconnect there as far as UI design paradigms are concerned. And that's why some sage words of advice from someone outside the coding trenches (and that covers most of "the community") would be invaluable.
Additionally, the Cyberdog tale really pointed out: it would be very helpful to the development of Gnome/KDE for the top architects to actually see some of the state-of-the-art technologies out there. I mean, half the features in Gnumeric are there because Miguel happened to have a copy of Windows and Excel. If he were to have a Macintosh running Cyberdog, or a PC running OS/2, or whatever, is there any reason to believe some of the good ideas in those systems would not find their way into Gnome?
It's a really bad fix to be in. It's kind of like asking yourself, at what point in the last century did it become too late to replace the now-ubiquitous and not-very-wrist-friendly QWERTY keyboard layout with a better one (Dvorak or otherwise?)
Perhaps the answer might be to develop two completely different UI designs, one chosen at compile time. One for MSOffice veterans, and one for those who want something better. I really think it would be a shame to make people who have never used MSOffice basically learn the MSOffice interface (or a sufficiently MSOffice-like interface) to get up to speed on their new cutting-edge free-software office suite.
Just wait until SGI starts selling mid-grade Linux workstations. They already have an X server for Nvidia hardware (in-house only for now, but not for long) that is said to blow Octanes out of the water. (Holy hardware T&L, Batman! I believe it!)
No timetables have been released, but I'd expect they'd have the line of workstations and the Oh-My-God-That's-Fast Nvidia drivers out by sometime this summer. At that rate, we can probably expect a port of Studio/Maya announced-- if not completed-- by the end of this year.
Indeed, with Linux, the question is never if, but when };-)
Batteries are usually designed with the possibility of recycling. That's why used car batteries (the regular kind) don't present an environmental hazard in disposal; auto garages already know what to do with them.
As for cars blowing up, remember, real life isn't like you see in the movies. It doesn't happen that often! Nowhere near enough to present an environmental issue.
The real environmental hit of electric cars are the power plants, which have to work harder to feed them when they're plugged in. So if your city is powered by a coal-fired plant, and everyone gets an electric car, the air ain't getting any cleaner.
But the advantage, then, is that-- in programmer's parlance-- the power source has been abstracted away from the car engine. So you can change the power source's implementation (say, from coal energy to wind energy) without breaking the rest of the system. Unlike the internal combustion engine, where the power source (gasoline) and application logic (engine) are so closely intertwined that it's impossible to port to any other architecture.
Methinks, however, even better than electric power for transportation is hydrogen power. You don't need super-high-tech batteries to power it, just armored fuel tanks, and an efficient way of producing the stuff. The exhaust products are (theoretically) just CO2+H20. (IIRC, however, since some nitrous oxides inevitably get into the air intake, you do get some icky exhaust hydrocarbons too, but nothing overwhelming)
Bad fonts under Netscape is a solved problem };-)
While anti-aliasing isn't involved, I think you'll find these a significant improvement over X11's out-of-the-box look:
X: A Site for Sore Eyes
(go to the bottom of the page)
Also, remember that OO is not the be-all end-all of programming approaches. OpenAL would be a lot less flexible and useful if it were implemented that way (as, say, a set of fully-OO C++ classes).
What make the approach they're taking really nice is that the API is staying clean. They're not trying to throw everything under the sun into the library-- they're keeping its scope razor-sharp, and leaving application-specific concerns like those to other libraries.
That way, you don't run into library overlap, which is incredibly bothersome if you're trying to write elegant code. (E.g. when you're using GLib, do you go with printf(), or g_print()? I hate having to decide things like that)
Kudos to Loki for following the footsteps of one of the most beautiful API's in existence, and for committing to keep it that way. I just know I'm going to write an OpenGL+OpenAL program someday, and I'm going to enjoy it immensely }:-)