The raytraced image could be made a little nicer by using soft shadows. But the kinds of things that the radiosity image is doing really are impossible to simulate with raytracing. You can't get the kind of thing that shows on the ceiling of that image, or the windowsills, using raytracing. The problem isn't a lack of "atmospheric effects," the problem is that to accurately model light, you have to take into account the fact that lights are not the only light sources in a scene; surfaces are lit by other brightly lit surfaces. Raytracing assumes that all light comes from light sources.
Raytracing is not THE elegant solution. It is one of many methods of rendering. It is very hard to simulate realistic global ligthing effects using raytracing (soft shadows and light reflecting indirectly off of other surfaces in addition to light coming directly from a light source). For example, take this image. You might think that's a fine raytraced image. But then compare it to this image, produced with radiosity. I think you'll agree that the second image looks *much* more real. Note the subtle shading across the back wall and ceiling, and also the way it is a little bit darker where the walls and ceiling meet at 90 degree angles. Effects like that would be nearly impossible to reproduce with raytracing, and don't even think about real-time rendering. Pictures like this really show how far real-time rendering has to go before it actually looks like reality.
Radiosity isn't *the* solution to rendering either. There are a whole range of lighting effects we see in daily life, and even radiosity only simulates some of them. For example, caustics (the funny patterns of light on the bottom of the pool). Even more general approaches to simulating light are being researched, but I don't really know if any of them are in use commercially yet.
Also, in case you were wondering, Quake/Unreal/etc actually use radiosity rendering as part of the map making process, then store the results in "light maps" which are basically textures that control how light or dark a wall is instead of its color. Pre-computing the lighting allows real-time rendering of nice levels with radiosity effects, but it has several problems. Firstly, light maps take up a lot of memory (there's one for each wall, while most other textures are used on more than one wall and are tiled repeatedly), so they are stored at a pretty low resolution to minimize memory usage. This produces a blocky "stair-step shadow" effect that you've probably seen if you've played Counter-Strike. Secondly, since all the lighting is pre-computed, you can't change it easily. If you want a light to turn on and off, you have to store two light maps for every wall affected by that light: one with it on and one with it off. This is why in most games where you can shoot out lights, there are only a select few that you can shoot out. This approach has even more trouble with moving objects or moving lights (flashlights, car headlights, explosions, muzzle flashes). Real-time OpenGL or DirectX style lighting is usually used for these types of lights and moving objects, but then you don't get the nice shadows and other lighting effects that radiosity gives you.
Already in progress at Freedesktop.org, thanks to the awesome Keith Packard. There's Cairo for vector graphics rendering and some unnamed project for double buffered/transparent/warpable windows (and yes there are screenshots, click the link!). Freedesktop.org is rapidly becoming host to many projects that are innovating in the Linux desktop arena. Check out some of the other software hosted there. Of particular interest (to me at least) is D-BUS combined with HAL.
Sounds to me like the F-4's bleed air feed was badly designed. I don't see how you can generalize that to saying "bleed air is always hard to use". Especially when it is the foundation for this aircraft's entire propulsion system already. The amount of bleed air needed to counteract the very small amount of spin is tiny in comparison to the amount it would take to lower the landing speed of an aircraft. And what does the VH-22 have to do with this? We're talking about the X-50A here.
It may be not enough to care, but if it is non-negligable, a small amount of the turbine's air output could be routed to a little nozzle on the back of the plane pointing sideways (in addition to the nozzles on the tips of the rotors and). You still wouldn't need a complex series of mechanical linkages to drive a secondary propeller.
Well, you can do free cross-platform QT development on any platform you want, as long as that platform runs X11 and has a POSIX-like interface (and what platform doesn't, nowadays?). Now that XFree86 is available for Windows (which is awesome, BTW) it should hardly be any trouble at all to develop QT/X11 applications for Windows as well. But if you want native QT/Mac or native QT/Windows, you still have to pay.
Well, I guess I should have been subscribed to the DNSEXT mailing list instead of the Zeroconf one, as apparently that's where all the real discussion is taking place. LLMNR hasn't been mentioned on the Zeroconf mailing list ever since I signed up. Actually Zeroconf has been kind of dead. The DNSEXT guys need to do some marketing for LLMNR or something (and get a better name, geez).
However, looking at the documents themselves (draft-ietf-dnsext-mdns-24.txt and draft-cheshire-dnsext-multicastdns.txt), it's not immediately obvious which one is farther along. They are both Internet-Drafts in the "standards track" category. I didn't realize that Microsoft's protocol was a work item of DNSEXT while Apple's was not.
mDNS isn't crap, it's cool, something like it been needed for a long time, and it's going through the IETF standards process. Apple's not "hijacking" anything. If you believe that using.local is a mistake, then you can bring up your concerns on the appropriate IETF working group. The IETF standardization process is completely open; anyone can join the mailing list and voice their concerns and get things changed.
Look here for info on mDNS and the related IETF working groups you can join.
Well, you could do that if there was an HTML control to substitute. AFAIK currently there is no ready-made HTML control with a built-in interface to substitute for a text field in either Mozilla or IE. There are ways of creating a HTML editor in Javascript (IE's contentEditable/designMode attribute and Mozilla's designMode attribute) but they come with no built-in interface beyond a flashing cursor. To actually *use* any of the html editor's features such as bold/italic/centered text or inserting links/tables/lists, you must provide a user interface to those features in Javascript. Furthermore, the Javascript API given to these features is bad. For example, creating a link will fail if there is no text selected, but there is no way to tell if any text is selected beforehand, and I don't even think there is an easy way to tell if the command succeeded afterward. Also, there is no way to insert arbitrary HTML code, you must use the couple of predefined "editing actions" given by Mozilla/IE.
Certainly if there was a suitable HTML control available, Javascript would be used to substitute it for a textarea when it was available, so older browsers could be supported. That would be the smart thing to do. But today's HTML editing controls require a whole interface built in Javascript as well, which is just retarded. Once again, what is needed is an <input type="html"> with a built-in interface.
Have you ever tried actually searching for something you were interested in buying on Froogle? I haven't had much luck. The pictures and quoted prices are often wrong or mismatched. Froogle's algorithms for separating multiple products posted on the same page seem not to work very well, so if you try to search for one product that has a few certain characteristics, you might get a page from a place that sells several products, and each has only one of the characteristics you're looking for. Froogle is not ready for prime time. A good product search engine really needs knowledge about specific product types so you can search for specific characteristics of the type of product you want. Full-text search just doesn't work as well, especially when different sites format their listings differently and Froogle's separation of products is so unreliable.
Interestingly, my mail client (Thunderbird) has no problem classifying these mails as spam. I got one advertising G3n3r1c V1@gr4, where over half of the words were spelled in l33t speak, plus there was a whole paragraph of random characters thrown in. It was still thrown in the junk bin. I'm very impressed with Thunderbird's filtering. No false positives so far!
Google lowers ranks of commercial sites to focus more on educational and informative sites? Sweet! I hope they do more! If I want to pay money for stuff, I'll look for ads or use Froogle. If I'm looking for information, I don't want search engine "optimizer" (more like search engine clogger) sites to fill the first three pages of results. I hate this attitude of entitlement webmasters get for their Google ranking. Google is not obligated to even include you in their index, much less rank you highly. Google is in the business of providing searchers with what they're looking for, and it may just be that your site just isn't what searchers really want.
Well, that's kinda cool, but the interface browsers are giving web designers is retarded. What is really needed is an with a built-in user interface, not a variety of incompatible Javascript APIs for performing editing-type actions on an iframe or div.
Doing it this way requires each site to have its own Javascript editing interface. Complex interfaces made in Javascript by web designers will be hard to use, buggy, and browser-specific with lots of ugly browser detection hacks (and probably not forward compatible with new browsers for this reason). They will not follow the user-interface guidelines for the platform they're running on and will not be able to adapt to different editing environments (such as a computer without a mouse, a PDA, or one of those speech browsers for the blind). The browser should provide the editing interface, because only the browser knows the capabilities of the user and the hardware.
I wouldn't expect a nontechnical person to grasp Wiki markup at all. I'm just imagining a very simple site that they can use to post text and maybe a few images (TWikis allow image attatchments fairly easily, can't say about the other varieties). Most blogs consist mainly of plain text anyway. Of course tables and resized pictures and things aren't going to be possible without an understanding of HTML (or the Wiki equivalent), but I don't think any other CMS or blog site out there would make those any easier.
What is really needed is a new "html editor" tag for XHTML. Like <input type="html">. Simple text browsers or embedded browsers could just treat these the same as text boxes, letting the user type HTML tags in directly if they want, while Mozilla/IE/Konqueror could provide a nice visual interface with buttons for bold, italics, links, creating a table, or whatever. This would enable a much nicer interface for forum/blog posts, and also a sort of Super-Wiki where absolutely everything is editable in a nice, easy visual way. Does XForms contain such a tag? That would be really cool.
Why are Wikis not easy to grasp? An "Edit This Page" button is pretty simple, and you don't have to worry about formatting or links or anything if you don't want to. I don't see how you could make a simple form any simpler than a Wiki. Maybe for a photo album you could, but for a simple editable page of text a Wiki is about as simple as you can get. If I spent 5 minutes explaining a Wiki to my mom I'm sure she'd have no trouble maintaining a simple webpage.
If you do want your own domain, how about a Wiki? It doesn't get much easier than a link called "Edit This Page". There are a few varieties to choose from; one with authentication and file attachment capabilities would work for a simple blog/photo gallery site. That way your family can have total control over every aspect of the website, but it can still be incredibly easy to modify.
There's one good thing about MS Windows GUI; it's very responsive. That's because everything uses the same widget set that is kept in memory with little extra overhead.
I used to think this, but not anymore. There are TONS of different UI toolkits used by popular Windows applications. Let me list some of the applications on my Windows install that use their own UI stuff:
Microsoft Office (2k and XP are subtle, but have you seen 2k3? It's blue!)
Visual Studio.NET
Windows Media Player
MSN Explorer
Windows Messenger
AIM
Maya
Photoshop
Acrobat reader
Opera
Firebird
Winamp
Steam (half-life, counter-strike)
Retarded Kodak software that came with my camera
A bunch more I can't even think of right now
Some of these apps do use some of the common windows controls (like Winamp 2 and AIM, in their configure dialogs). But for the most part, each of these applications draws its buttons a different way and acts a little differently, which means they are using their own custom UI code. Some applications do it for portability (Firebird, Photoshop, Opera), others to it to look different (Steam, Winamp, WMP), others only God knows the reasons (Office, MSN Explorer). But each of these applications uses its own separate interface code. It's getting to be worse than Linux.
TCP/IP doesn't need to be replaced. IP is not heirarchical by nature. The Internet is already not a strict heirarchy. There is a sort of tiered structure with big backbone providers at the top, and small companies and individuals at the bottom, but the connections don't form a tree; there are lots of cycles and cross-connections. The problem with a fully decentralized P2P mesh-type network is routing. Solve the routing problem, and TCP/IP will work just fine in that environment. If you don't solve the routing problem, replacing TCP/IP won't help.
Of course this brings up the question as to how we then find each other. One solution is to do something similar to what NIC's do on a network segment and only allow each host to receive information intended for them.
You're talking nonsense here. NICs on a network segment see every packet sent or recieved by everyone on the same segment. On a *switched* network traffic is routed so that only the destination computer sees it, but the switches themselves still see every packet. This kind of thing doesn't scale up. In a global network you really need to do more sophisticated routing, which means you need registered globally unique address ranges. I think you need to learn more about how the Internet works now before proposing drastic changes.
is intended to be used for posting code fragments. It uses a monospace font, indents the code fragment automatically, and tries to preserve indentation and whitespace as much as possible. Except that I tried it just now and it appears to be broken, and doesn't preserve indentation at all. Oh well. See the Slashdot FAQ entry on posting modes.
Slashcode already does quite a bit of munging on the html you give it. It disallows some (most) tags and tag attributes, implements the special tag that isn't a real HTML tag, and closes all of your open tags. It probably wouldn't be too hard to fix it up to correct nesting issues. If Slashdot was serious about moving to XHTML, this would probably be the least of their worries.
Personally, I think what is needed (as long as we're being wildly optomistic here) is not Yet Another Linux Distro, but instead a whole new OS based on top of the linux kernel and drivers.
A whole new set of standard user-space tools to replace the old UNIX tools (or at least coexist with them for backwards compatibility).
A new OS could provide a standard config file format and framework for OS services (/etc is a mishmash of horrible kludges), a new modern hardware abstraction layer for dealing with devices and hardware detection (/dev was innovative in the 70s but it's a disaster now), a new high-level filesystem API based around URLs (imagine http:// built into the OS, or devices:/ or whatever), a new standard GUI layer, and all sorts of cool other stuff.
(let me add another parenthetical expression here, I don't think this post has enough yet)
This is why smtp needs an overhaul. We need a new protocol for transferring mail. Actually two: One for clients to send mail to servers, and a *separate* one for servers to send mail to each other. In this new protocol, only the mail server with the MX DNS record for domain foo.com would be able to send mail with a return address at foo.com. Any other mail would be rejected by the recieving server. This would make it a lot harder to forge random From addresses. Also there would be no such thing as a mail relay, all mail would go straight from the source server to the destination server. IP does the routing; having routing in an application protocol like SMTP is a stupid idea. All servers running the new client to server protocol would require strong authentication before accepting messages for transfer, to prevent the open relay problem. Servers for this new mail protocol could accept SMTP messages but mark them as "insecure" or "likely spam" for users. Why hasn't this been done already? These kinds of things would make the spam problem a lot more managable.
Also, there's Apt Pinning. You can install a stable system, then upgrade the specific programs you use to their versions in sid (which is most often the newest available version of the program). And if they don't work, you can downgrade back to the stable versions.
I think KJSEmbed along with the QT UI designer could become the VB replacement everyone says they want. No, it's not BASIC, but who cares? Javascript is pretty easy. With KDE's strong application framework at your disposal you can create full applications with menus, toolbars, config dialogs, keyboard shortcuts, network-transparent I/O, etc. with only a small amount of code. With a really simple and easy-to-use IDE, KJSEmbed could be a VB killer.
Slashdot Mirror
The raytraced image could be made a little nicer by using soft shadows. But the kinds of things that the radiosity image is doing really are impossible to simulate with raytracing. You can't get the kind of thing that shows on the ceiling of that image, or the windowsills, using raytracing. The problem isn't a lack of "atmospheric effects," the problem is that to accurately model light, you have to take into account the fact that lights are not the only light sources in a scene; surfaces are lit by other brightly lit surfaces. Raytracing assumes that all light comes from light sources.
Radiosity isn't *the* solution to rendering either. There are a whole range of lighting effects we see in daily life, and even radiosity only simulates some of them. For example, caustics (the funny patterns of light on the bottom of the pool). Even more general approaches to simulating light are being researched, but I don't really know if any of them are in use commercially yet.
Also, in case you were wondering, Quake/Unreal/etc actually use radiosity rendering as part of the map making process, then store the results in "light maps" which are basically textures that control how light or dark a wall is instead of its color. Pre-computing the lighting allows real-time rendering of nice levels with radiosity effects, but it has several problems. Firstly, light maps take up a lot of memory (there's one for each wall, while most other textures are used on more than one wall and are tiled repeatedly), so they are stored at a pretty low resolution to minimize memory usage. This produces a blocky "stair-step shadow" effect that you've probably seen if you've played Counter-Strike. Secondly, since all the lighting is pre-computed, you can't change it easily. If you want a light to turn on and off, you have to store two light maps for every wall affected by that light: one with it on and one with it off. This is why in most games where you can shoot out lights, there are only a select few that you can shoot out. This approach has even more trouble with moving objects or moving lights (flashlights, car headlights, explosions, muzzle flashes). Real-time OpenGL or DirectX style lighting is usually used for these types of lights and moving objects, but then you don't get the nice shadows and other lighting effects that radiosity gives you.
Already in progress at Freedesktop.org, thanks to the awesome Keith Packard. There's Cairo for vector graphics rendering and some unnamed project for double buffered/transparent/warpable windows (and yes there are screenshots, click the link!). Freedesktop.org is rapidly becoming host to many projects that are innovating in the Linux desktop arena. Check out some of the other software hosted there. Of particular interest (to me at least) is D-BUS combined with HAL.
You're in luck: Transgaming sells API implementations that support games like D2 and CS on Linux. (Actually they sell "subscriptions" but whatever.)
Sounds to me like the F-4's bleed air feed was badly designed. I don't see how you can generalize that to saying "bleed air is always hard to use". Especially when it is the foundation for this aircraft's entire propulsion system already. The amount of bleed air needed to counteract the very small amount of spin is tiny in comparison to the amount it would take to lower the landing speed of an aircraft. And what does the VH-22 have to do with this? We're talking about the X-50A here.
It may be not enough to care, but if it is non-negligable, a small amount of the turbine's air output could be routed to a little nozzle on the back of the plane pointing sideways (in addition to the nozzles on the tips of the rotors and). You still wouldn't need a complex series of mechanical linkages to drive a secondary propeller.
Well, you can do free cross-platform QT development on any platform you want, as long as that platform runs X11 and has a POSIX-like interface (and what platform doesn't, nowadays?). Now that XFree86 is available for Windows (which is awesome, BTW) it should hardly be any trouble at all to develop QT/X11 applications for Windows as well. But if you want native QT/Mac or native QT/Windows, you still have to pay.
However, looking at the documents themselves (draft-ietf-dnsext-mdns-24.txt and draft-cheshire-dnsext-multicastdns.txt), it's not immediately obvious which one is farther along. They are both Internet-Drafts in the "standards track" category. I didn't realize that Microsoft's protocol was a work item of DNSEXT while Apple's was not.
mDNS isn't crap, it's cool, something like it been needed for a long time, and it's going through the IETF standards process. Apple's not "hijacking" anything. If you believe that using .local is a mistake, then you can bring up your concerns on the appropriate IETF working group. The IETF standardization process is completely open; anyone can join the mailing list and voice their concerns and get things changed.
Look here for info on mDNS and the related IETF working groups you can join.
Certainly if there was a suitable HTML control available, Javascript would be used to substitute it for a textarea when it was available, so older browsers could be supported. That would be the smart thing to do. But today's HTML editing controls require a whole interface built in Javascript as well, which is just retarded. Once again, what is needed is an <input type="html"> with a built-in interface.
Have you ever tried actually searching for something you were interested in buying on Froogle? I haven't had much luck. The pictures and quoted prices are often wrong or mismatched. Froogle's algorithms for separating multiple products posted on the same page seem not to work very well, so if you try to search for one product that has a few certain characteristics, you might get a page from a place that sells several products, and each has only one of the characteristics you're looking for. Froogle is not ready for prime time. A good product search engine really needs knowledge about specific product types so you can search for specific characteristics of the type of product you want. Full-text search just doesn't work as well, especially when different sites format their listings differently and Froogle's separation of products is so unreliable.
Interestingly, my mail client (Thunderbird) has no problem classifying these mails as spam. I got one advertising G3n3r1c V1@gr4, where over half of the words were spelled in l33t speak, plus there was a whole paragraph of random characters thrown in. It was still thrown in the junk bin. I'm very impressed with Thunderbird's filtering. No false positives so far!
Google lowers ranks of commercial sites to focus more on educational and informative sites? Sweet! I hope they do more! If I want to pay money for stuff, I'll look for ads or use Froogle. If I'm looking for information, I don't want search engine "optimizer" (more like search engine clogger) sites to fill the first three pages of results. I hate this attitude of entitlement webmasters get for their Google ranking. Google is not obligated to even include you in their index, much less rank you highly. Google is in the business of providing searchers with what they're looking for, and it may just be that your site just isn't what searchers really want.
Doing it this way requires each site to have its own Javascript editing interface. Complex interfaces made in Javascript by web designers will be hard to use, buggy, and browser-specific with lots of ugly browser detection hacks (and probably not forward compatible with new browsers for this reason). They will not follow the user-interface guidelines for the platform they're running on and will not be able to adapt to different editing environments (such as a computer without a mouse, a PDA, or one of those speech browsers for the blind). The browser should provide the editing interface, because only the browser knows the capabilities of the user and the hardware.
What is really needed is a new "html editor" tag for XHTML. Like <input type="html">. Simple text browsers or embedded browsers could just treat these the same as text boxes, letting the user type HTML tags in directly if they want, while Mozilla/IE/Konqueror could provide a nice visual interface with buttons for bold, italics, links, creating a table, or whatever. This would enable a much nicer interface for forum/blog posts, and also a sort of Super-Wiki where absolutely everything is editable in a nice, easy visual way. Does XForms contain such a tag? That would be really cool.
Why are Wikis not easy to grasp? An "Edit This Page" button is pretty simple, and you don't have to worry about formatting or links or anything if you don't want to. I don't see how you could make a simple form any simpler than a Wiki. Maybe for a photo album you could, but for a simple editable page of text a Wiki is about as simple as you can get. If I spent 5 minutes explaining a Wiki to my mom I'm sure she'd have no trouble maintaining a simple webpage.
If you do want your own domain, how about a Wiki? It doesn't get much easier than a link called "Edit This Page". There are a few varieties to choose from; one with authentication and file attachment capabilities would work for a simple blog/photo gallery site. That way your family can have total control over every aspect of the website, but it can still be incredibly easy to modify.
I used to think this, but not anymore. There are TONS of different UI toolkits used by popular Windows applications. Let me list some of the applications on my Windows install that use their own UI stuff:
Some of these apps do use some of the common windows controls (like Winamp 2 and AIM, in their configure dialogs). But for the most part, each of these applications draws its buttons a different way and acts a little differently, which means they are using their own custom UI code. Some applications do it for portability (Firebird, Photoshop, Opera), others to it to look different (Steam, Winamp, WMP), others only God knows the reasons (Office, MSN Explorer). But each of these applications uses its own separate interface code. It's getting to be worse than Linux.
Of course this brings up the question as to how we then find each other. One solution is to do something similar to what NIC's do on a network segment and only allow each host to receive information intended for them.
You're talking nonsense here. NICs on a network segment see every packet sent or recieved by everyone on the same segment. On a *switched* network traffic is routed so that only the destination computer sees it, but the switches themselves still see every packet. This kind of thing doesn't scale up. In a global network you really need to do more sophisticated routing, which means you need registered globally unique address ranges. I think you need to learn more about how the Internet works now before proposing drastic changes.
is intended to be used for posting code fragments. It uses a monospace font, indents the code fragment automatically, and tries to preserve indentation and whitespace as much as possible. Except that I tried it just now and it appears to be broken, and doesn't preserve indentation at all. Oh well. See the Slashdot FAQ entry on posting modes.
Slashcode already does quite a bit of munging on the html you give it. It disallows some (most) tags and tag attributes, implements the special tag that isn't a real HTML tag, and closes all of your open tags. It probably wouldn't be too hard to fix it up to correct nesting issues. If Slashdot was serious about moving to XHTML, this would probably be the least of their worries.
A new OS could provide a standard config file format and framework for OS services (/etc is a mishmash of horrible kludges), a new modern hardware abstraction layer for dealing with devices and hardware detection (/dev was innovative in the 70s but it's a disaster now), a new high-level filesystem API based around URLs (imagine http:// built into the OS, or devices:/ or whatever), a new standard GUI layer, and all sorts of cool other stuff.
(let me add another parenthetical expression here, I don't think this post has enough yet)
This is why smtp needs an overhaul. We need a new protocol for transferring mail. Actually two: One for clients to send mail to servers, and a *separate* one for servers to send mail to each other. In this new protocol, only the mail server with the MX DNS record for domain foo.com would be able to send mail with a return address at foo.com. Any other mail would be rejected by the recieving server. This would make it a lot harder to forge random From addresses. Also there would be no such thing as a mail relay, all mail would go straight from the source server to the destination server. IP does the routing; having routing in an application protocol like SMTP is a stupid idea. All servers running the new client to server protocol would require strong authentication before accepting messages for transfer, to prevent the open relay problem. Servers for this new mail protocol could accept SMTP messages but mark them as "insecure" or "likely spam" for users. Why hasn't this been done already? These kinds of things would make the spam problem a lot more managable.
Also, there's Apt Pinning. You can install a stable system, then upgrade the specific programs you use to their versions in sid (which is most often the newest available version of the program). And if they don't work, you can downgrade back to the stable versions.
I think KJSEmbed along with the QT UI designer could become the VB replacement everyone says they want. No, it's not BASIC, but who cares? Javascript is pretty easy. With KDE's strong application framework at your disposal you can create full applications with menus, toolbars, config dialogs, keyboard shortcuts, network-transparent I/O, etc. with only a small amount of code. With a really simple and easy-to-use IDE, KJSEmbed could be a VB killer.