I think, just for a moment taking the position of the user in your situation, that I would class that system as "annoying".
Sure, it makes your job easier, but I can't help thinking that there must be a less anal and beaureucratic way of handling the situation. The part about requiring the ID number to match the hash seems like it would be especially frustrating. Under your system, a semi-technical user would be unable to report a fault even if he or she has quite a good idea what the problem might be just because the user didn't manage to take a picture of the problem.
Increasing tax would be a pretty bad solution, but it would work unless it also got wasted.
Of course, removing the waste is the ideal solution. Removing the waste and increasing tax (but not going crazy) would allow public services to improve faster, and perhaps tax can be lowered later once the system's working more efficiently and a surplus is discovered.
That's true of everything, including things that most consider a lot more important than NASA.
I live in the UK, so there's no NASA to worry about funding. However, it really annoys me when, in the run-up to elections, the political parties start talking about reducing taxes, amongst other things. If the system was running perfectly and there was a funding surplus, I'd say cutting taxes is a good idea, but while hospitals continue to close and downsize, and education funding drops through the floor, we either need to raise taxes or optimise the systems that are in place.
I hear that there are over ten managers per patient in national health service hospitals here. I also see schools wasting money on computers that are five times faster than mine just to run Microsoft Office. The money's going to the wrong places. Either refocus the existing money or increase tax. Those are the only solutions.
This applies to NASA in the US, too. I wish voters would think it through and realise that, until we've got the system working properly, tax decreases are a bad thing, and that they should vote for parties which don't claim they are going to cut tax. That's the problem with allowing everyone to vote, though, I guess!
The default rendering of otherwise-unstyled XHTML documents is up to the browser implementor, and is not specified in the XHTML specification because XHTML (now) is a completely semantic markup language.
The CSS specification (mostly) specifies the result that each property should have and the interactions between them. Of course, today's browsers implement the specification partially and with many bugs. The fault here lies, in most cases, with the browser developers, not with the specifications. There are a few vague spots in the CSS spec, however; ideally, the browser developers would seek clarification from W3C, but pressures to get the product out the door make that unfeasible I suppose.
Now that every browser anyone would dream of using supports IMG in some form, even if it's just replacing the element with the contents of the ALT element, it's easy to forget about its heritage and not correctly shame the creators of this, one-broken-always-broken element.
IMG was added to Mosaic back in the day, and after it was implemented it was submitted for peer review. The "peers" correctly noted that the use of an 'alt' attribute to handle browsers which cannot display the image is inadequate because pre-IMG browsers will not render it at all. In addition, it can only accept plain text and not full markup, so it is impossible to provide proper fallbacks in non-trivial cases. Sadly, the Mosaic developer responsible for IMG decided that since it had already been implemented as submitted, and Mosaic was the browser of the time, it wasn't worth the trouble to rewrite the support for this element in their tag-soup parser.
Today we have OBJECT which works as suggested by the peer review of IMG back in the day, but IMG has become so ingrained that no-one can feasibly use it. OBJECT is clearly a superior solution, supporting all kinds of object and providing multi-tiered fallback simply by nesting OBJECT elements within each other and finally nesting other elements such as IMG.
I'm not so sure that I agree with this new "everything is potentially an image" idea, though. It seems nice in theory, but just that example of a SPAN element inside a P element shows that it's all just an awful hack. It's a good start, but it seems like they didn't really think it through properly.
Unfortunately, since the vast majority of current documents are purely presentational markup, current search engines just seem to strip the tags and treat the result as one big bag of words.
If headings had an advantage, you'd suddenly see thousands of porn/spam sites enclosing the entire page in an H1 element and optionally using CSS to override the default presentation of common browsers.
PNG supports GIF-like palette transparency, where you nominate a palette index which will allow the background to "show through".
As you might expect, though, palette transparency only works if you create an indexed (palette-based) PNG images. Most people tend to make 32-bit non-indexed PNG images, which support alpha channel (partial transparency). IE for Windows renders alpha-channel PNG images onto a solid background, thus defeating the object.
I don't know how you set the palette transparency in Photoshop, but make sure your image is using indexed color first.
My 40GB drive actually has a jumper on it which makes it pretend to be a 32GB drive so that such BIOSes can talk to it. Since this disk is in a PII box with a cheap mobo that jumper is currently active, going back to when it actually mattered what the BIOS thought.
It hadn't really occured to me that these days the BIOS's opinion of my drive doesn't matter once the OS is loaded, so perhaps I can reclaim the other 8GB of the drive with some careful partitioning...
If this won't prevent people from modding their machines then it won't curb the problem of illegal game distribution, so what's the point? You've just made it harder for the people who have a legitimate hobby (ethically) to execute that hobby with no benefit tradeoff.
Avast ye!
Re:Slightly OT: Reserved IP adresses in IPv6
on
IPv6 is Here
·
· Score: 1
Using global addresses when you aren't on the global network seems like a mistake to me.
Retaining the local addresses when joining the Internet makes for much easier migration than a flat-out complete renumbering. My concern is flexibility and convenience, not security.
One thing I find amusing is that the term "firewall" comes from the practice of strategically-placing fire-retardant walls in buildings to slow the spread of fire in large office blocks, schools etc. Essentially, the firewall is there to keep the fire from escaping the area it started. These so-called "reverse firewalls" are closer to the idea of a traditional fire wall than the more usual model of stopping the fire from entering.
(of course, there are cases where a fire wall is there to keep the fire out, such as around an important area of a building such as a data repository.)
Re:Slightly OT: Reserved IP adresses in IPv6
on
IPv6 is Here
·
· Score: 1
Hosts can have more than one address. My private LAN here currently has link-local IPv6 addresses because I'm not in a situation where it is feasible to be on the IPv6 Internet. If, in the future, I do have the need and the ability to use public IPv6 I will assign second global-scope addresses to each host and keep the local addresses.
Now take this situation and place it in my original scenario where there are two physical networks and a router between them, currently using some kind of private address range. Later they get "real" Internet access, so rather than renumbering all of my hosts I simply give them two addresses so that the private addresses go on working and each host also has public addresses. No NAT, just a different internal idea of addresses.
Of course, if there's no private address range available this isn't an option, and so I would have to renumber. That would be annoying. This is why I'm curious as to why the private address range in IPv6 is being deprecated.
Re:Slightly OT: Reserved IP adresses in IPv6
on
IPv6 is Here
·
· Score: 1
Not all networks are on the Internet.
Sure, I know if they're not on the Internet then technically they can use any IP range and probably don't need the overhead of IPv6, but it's nice to play by the rules so you don't get headaches if the network ever does somehow get an Internet connection.
Even with everyone connected to the Internet, there's never going to be just one network. We're always going to have to deal with weird situations where there's some kind of bridge between an odd special network and the Internet, whether due to logistical or simply administrative reasons.
I don't use RSS (and Atom) for reading the news, I use it to monitoring posts in people's weblogs and sometimes even the comments to them if the content producer has been nice enough to make those available.
I agree that using RSS to read "real news" is like trying to read someone else's newspaper from the other end of a train car.
A possiblility is to try to reinvent the NNTP model over HTTP. Have big "super-nodes" which poll the originating feeds and store the result in some big database, and then allow users to pull down one big feed containing stuff from all of the sources they are interested in.
Of course, there'd have to be something in it for the super-nodes, and I suspect what would happen is that they would charge a nominal fee, or perhaps bundle it alongside some other, similar service. One example of this is LiveJournal, which currently distributes RSS and Atom feed content to any interested LiveJournal user via the "friends page" mechanism from a single database, so there's only one poll per hour (or so). All they need now is some kind of feed of the "friends view" and you have a special version of a feed distributor with some value-add: you get all of your LiveJournal friends' content in there too.
Bare RSS isn't set up for this since it can't support per-item source information, but Atom can do it and RSS can be extended through namespaces to contain the relevant info as long as it becomes popular enough that clients support it.
In fact, if this were to be done, it would also be useful to have an optional "intelligent poll" mode where the client tells the server a magic token it got on its last poll which the server can then use to give a delta feed rather than a fixed feed. This would have to be optional, since the CPU burn of it vs. just copying a static file to a socket would probably only be a win on big sites like Slashdot and BBC News Online.
In fact, it looks like the Atom guys already thought of all this. Check out AggregateFeeds, SuperAggregator and the overly-long PossibleHTTPExtensionForEfficientFeedTransfer entries in the Atom Wiki. I didn't read it all through in depth, but it looks like they're talking about the same thing I'm talking about.
BitTorrent is the wrong model. What you want is something more like the NNTP model, but with persistant connections rather than polling. Content producers would sign their content (to prove it hasn't been modified/faked) and push it into a Peer-to-Peer cloud. The content item then gets shoved around the cloud so that interested parties can store it.
The most efficient approach is probably to create small clouds surrounding each content source rather than one big cloud shoving everything around, so the problem just becomes handling the initial bootstrap (like a BitTorrent tracker) rather than handling the content distribution to each client individually. However, the "one big cloud" solution also has advantages. It means that eventually people will be able to push in content which isn't from any website at all and have others subscribe to it. Clients would watch all passing data and snag what they are interested in. Replies to articles wouldn't go back through the originating server, they'd just get pushed around the cloud with a reply marker and clients would be able to produce a threaded display much as a USENET newsreader does.
Of course, this all needs clever swarming/distribution algorithms to avoid swamping all users with loads of data they don't care in the slightest about, but there's plenty of prior art out there to base it on.
Re:Slightly OT: Reserved IP adresses in IPv6
on
IPv6 is Here
·
· Score: 1
What about if I have two private networks and I want to route between them? What IPv6 range should I use for the addresses that both networks can see?
I must admit I don't really play N64 games. I toyed with Project64 a long time ago on a different system and put my lack of success down to the limitations of that box rather than to Project64 itself.
Keeping the sound in sync is a hard thing for an emulator to do since it must, of course, be running at exactly the same speed as the system it is emulating to keep the sound from being choppy. When dealing with this issue in the past on older systems I've often just turned off the sound, since it's rarely necessary anyway and I can just put some music on my stereo system or whatever. I know this isn't really a solution, but at least you still get to play the games if it's only sound that is broken.
Buggy emulation (leading to locks and crashes) is, of course, not possible to work around. You just have to play a different game and wait for the emulator developers to fix it. I'm sad to say that my TV box runs Windows XP Home right now so I can't comment on emulator performance in Linux. This choice was driven by the lack of decent linux support for the TV chip on my graphics card -- it'll turn it on, and I can get all sorts of interesting low-level access to the chip, but I was too lazy to tweak it to get the good picture and easy overscan switching I can get with the manufacturer's drivers and software in Windows.
As for discussing emulation: I'm not really scared of Nintendo here. If they're going to go after anyone, they'll be going after the emulator developers and not the users. (The grey area about the copying of the games to ROM images notwithstanding.)
My standard phone line (in the UK) isn't included in the telephone directory either. It's an option available to all users of the phone system here, and my telco doesn't include customers by default. This is actually probably due more to the administrative issues of passing customer details over to BT for the directory, but it suits me anyway.
Isn't being excluded from the telephone directory allowed in the US?
Judging by ActiveState's Visual Perl (and the related products for Python and XSLT), Visual Studio.NET allows you to plug in support for new languages.
It might be worth investigating how hard it would be to adapt the ASP.NET stuff into a PHP IDE which works identically to ASP.NET's, or if necessary re-implement parts of it so that PHP has a comparable Visual Studio interface.
I don't use Visual Studio or ASP.NET, so I've no idea what the IDE is like, but I assume it can't be that special since, after all, we're just talking about website templates and backend code here, right?
I remember when J2ME first became popular and I heard 12 and 13 year olds sitting in the street talking about how their phones support "Java" and how that means that they can play games on it.
Similar things happened several times, and most of the time it was clear that none of them really knew what Java was or how it related to games or phones, it's just a name for a thing the phone does like "polyphonic ringtones" or "WAP".
Also, I would have trouble buying "Java Powered" unless the phone's core software was running in a JVM. "Runs trivial little games and applications using Java" isn't the same as "Wouldn't work at all without Java".
The first few generations of Microsoft's wizards were closer to Apple Guide. I can't remember which app did it first, but the one I dealt with most was an old version of Microsoft Publisher, since my family liked to use it to produce flashy layouts for homework assignments and the like.
The wizards in Publisher would ask you questions and then, once the wizard is complete, it would give you the option of either just doing whatever you wanted to do, or doing it slowly, simulating selections on the menus and dialog boxes so that you could see what the program was doing to complete the task.
Of course, having the user do it for himself is probably a much better learning aid, but this at least was a reasonable compromise between getting the job done efficiently the first time and letting the user know how to do it "the normal way" in the future.
Sadly, this feature was phased out somewhere between Publisher 98 for Windows 3 and the Win32 version, and all of the other Microsoft applications lost it too. Now Microsoft is wizard-mad, and a lot of things in Windows can only be done with wizards: they are the means by which you do things, rather than a teacher to help you learn the long way. In some cases, where the list of tasks is by nature very linear, this works. In other cases, I often just wish it'd give me a dialog box containing all of the relevant options with sensible defaults and just let me pick out what I need to change.
I would argue that in a well-designed application the backend should have little or no relationship with the UI. The backend should provide completely generic access to retrieve or do whatever the app is supposed to do. The UI should then talk to the backend in response to user commands.
Before you cry foul note that I'm not talking about a one-to-one correspondance between the user interface "commands" and the backend API. All I am saying is that the code to handle the user interface can do whatever is necessary to allow the intuitive interface to do what it needs to do as a sequence of backend API calls and some (potentially quite complicated) glue code.
Mixing in the UI with the backend will just cause problems later when things need to change in the backend or the UI. Keeping them cleanly separated, with the backend clean and general, means that theoretically you could strip off the entire UI and put a different one in its place, or even have several different user interfaces all calling the same backend API, providing a Gtk+ interface, a Win32 interface and an OS X interface, and even web and command line interfaces.
It doesn't matter what you do first as long as each layer is clearly separated from the other layers except for a carefully-interfaced tree relationship. (The UI depends on the backend, the backend depends on the underlying data source)
What I sometimes call "VB design" (after Visual Basic), where the GUI *is* the application and the backend depends on the UI, is one of the worst design methodologies ever attempted.
Of course, all of this is hypothetical. Most application developers don't have the patience to keep the backend clean and generic, and inevitably UI-oriented junk creeps in over time... or worse, they spend ages designing the back end and then have no energy left for the UI and it just ends up being a launcher for API functions. Simply saying "do the UI first" isn't enough, though. I say do them in whatever order you like but put the required amount of effort into all parts of the application, not just the backend, and keep clear in your mind what is interface and what is backend.
I like to think I've got enough theory in my head to have a good whack at user-interface design, but of course I'm not going to claim to be an expert. There are two main skills we need for user interfaces in open source software:
the ability to concieve, design and implement a usable user interface
the ability to look at a user interface designed by someone else and critique it
The second of these is the easier of the two, and I think most people can make some constructive comments about the pros and cons of a user interface designed by someone else. The first item, however, is the hardest part. To start from scratch like that requires quite a lot of background, and while some developers make a reasonable stab at it, usually by responding to how other developers handled a similar situation, that can't work for all cases.
Until such a time when we have qualified UI engineers contributing to open source projects, I think it's useful to increase the feedback between the two tasks above. The original developer uses some simple UI background to design an initial interface, then throw it to other developers and interested users and invite feedback on the interface specifically. The developers, in their role as developers, will probably point out some inconsistancies with the simple rules they have learnt, but the developers can also take the role of users and see what they find hard to do in the software.
Once that is fed back, the user interface can be refined just like the rest of the software until it's good to go. This refinement process works for the innards of the software, where perhaps the set of people able to make good comments is smaller, but everyone can have a point of view on a user interface because everyone knows what they are trying to do and what's obstructing them from doing it. Of course, we have to remember not to go overboard as some goals will be more "common" than others, but we make decisions like this in software design every day so applying similar priorities to the UI suggestions should come naturally to any seasoned open-source developer.
All my PC-connected-to-TV is used for is emulating old consoles. I just have a couple of USB control pads and some nice emulators, some crappy software to provide an easy interface to it, and I can sit in my living room and play Super Mario Kart, Streets of Rage or one of many more games with my friends without having to have fifteen consoles all over the place.
The PC isn't good enough to emulate an X-Box, Playstation2 or a Game Cube but it can handle basically everything before that. Most games since the Playstation have been pretty useless and/or available on PC anyway...
Slashdot Mirror
I think, just for a moment taking the position of the user in your situation, that I would class that system as "annoying".
Sure, it makes your job easier, but I can't help thinking that there must be a less anal and beaureucratic way of handling the situation. The part about requiring the ID number to match the hash seems like it would be especially frustrating. Under your system, a semi-technical user would be unable to report a fault even if he or she has quite a good idea what the problem might be just because the user didn't manage to take a picture of the problem.
Increasing tax would be a pretty bad solution, but it would work unless it also got wasted.
Of course, removing the waste is the ideal solution. Removing the waste and increasing tax (but not going crazy) would allow public services to improve faster, and perhaps tax can be lowered later once the system's working more efficiently and a surplus is discovered.
That's true of everything, including things that most consider a lot more important than NASA.
I live in the UK, so there's no NASA to worry about funding. However, it really annoys me when, in the run-up to elections, the political parties start talking about reducing taxes, amongst other things. If the system was running perfectly and there was a funding surplus, I'd say cutting taxes is a good idea, but while hospitals continue to close and downsize, and education funding drops through the floor, we either need to raise taxes or optimise the systems that are in place.
I hear that there are over ten managers per patient in national health service hospitals here. I also see schools wasting money on computers that are five times faster than mine just to run Microsoft Office. The money's going to the wrong places. Either refocus the existing money or increase tax. Those are the only solutions.
This applies to NASA in the US, too. I wish voters would think it through and realise that, until we've got the system working properly, tax decreases are a bad thing, and that they should vote for parties which don't claim they are going to cut tax. That's the problem with allowing everyone to vote, though, I guess!
The default rendering of otherwise-unstyled XHTML documents is up to the browser implementor, and is not specified in the XHTML specification because XHTML (now) is a completely semantic markup language.
The CSS specification (mostly) specifies the result that each property should have and the interactions between them. Of course, today's browsers implement the specification partially and with many bugs. The fault here lies, in most cases, with the browser developers, not with the specifications. There are a few vague spots in the CSS spec, however; ideally, the browser developers would seek clarification from W3C, but pressures to get the product out the door make that unfeasible I suppose.
Now that every browser anyone would dream of using supports IMG in some form, even if it's just replacing the element with the contents of the ALT element, it's easy to forget about its heritage and not correctly shame the creators of this, one-broken-always-broken element.
IMG was added to Mosaic back in the day, and after it was implemented it was submitted for peer review. The "peers" correctly noted that the use of an 'alt' attribute to handle browsers which cannot display the image is inadequate because pre-IMG browsers will not render it at all. In addition, it can only accept plain text and not full markup, so it is impossible to provide proper fallbacks in non-trivial cases. Sadly, the Mosaic developer responsible for IMG decided that since it had already been implemented as submitted, and Mosaic was the browser of the time, it wasn't worth the trouble to rewrite the support for this element in their tag-soup parser.
Today we have OBJECT which works as suggested by the peer review of IMG back in the day, but IMG has become so ingrained that no-one can feasibly use it. OBJECT is clearly a superior solution, supporting all kinds of object and providing multi-tiered fallback simply by nesting OBJECT elements within each other and finally nesting other elements such as IMG.
I'm not so sure that I agree with this new "everything is potentially an image" idea, though. It seems nice in theory, but just that example of a SPAN element inside a P element shows that it's all just an awful hack. It's a good start, but it seems like they didn't really think it through properly.
Unfortunately, since the vast majority of current documents are purely presentational markup, current search engines just seem to strip the tags and treat the result as one big bag of words.
If headings had an advantage, you'd suddenly see thousands of porn/spam sites enclosing the entire page in an H1 element and optionally using CSS to override the default presentation of common browsers.
PNG supports GIF-like palette transparency, where you nominate a palette index which will allow the background to "show through".
As you might expect, though, palette transparency only works if you create an indexed (palette-based) PNG images. Most people tend to make 32-bit non-indexed PNG images, which support alpha channel (partial transparency). IE for Windows renders alpha-channel PNG images onto a solid background, thus defeating the object.
I don't know how you set the palette transparency in Photoshop, but make sure your image is using indexed color first.
My 40GB drive actually has a jumper on it which makes it pretend to be a 32GB drive so that such BIOSes can talk to it. Since this disk is in a PII box with a cheap mobo that jumper is currently active, going back to when it actually mattered what the BIOS thought.
It hadn't really occured to me that these days the BIOS's opinion of my drive doesn't matter once the OS is loaded, so perhaps I can reclaim the other 8GB of the drive with some careful partitioning...
If this won't prevent people from modding their machines then it won't curb the problem of illegal game distribution, so what's the point? You've just made it harder for the people who have a legitimate hobby (ethically) to execute that hobby with no benefit tradeoff.
Avast ye!
Using global addresses when you aren't on the global network seems like a mistake to me.
Retaining the local addresses when joining the Internet makes for much easier migration than a flat-out complete renumbering. My concern is flexibility and convenience, not security.
One thing I find amusing is that the term "firewall" comes from the practice of strategically-placing fire-retardant walls in buildings to slow the spread of fire in large office blocks, schools etc. Essentially, the firewall is there to keep the fire from escaping the area it started. These so-called "reverse firewalls" are closer to the idea of a traditional fire wall than the more usual model of stopping the fire from entering.
(of course, there are cases where a fire wall is there to keep the fire out, such as around an important area of a building such as a data repository.)
Hosts can have more than one address. My private LAN here currently has link-local IPv6 addresses because I'm not in a situation where it is feasible to be on the IPv6 Internet. If, in the future, I do have the need and the ability to use public IPv6 I will assign second global-scope addresses to each host and keep the local addresses.
Now take this situation and place it in my original scenario where there are two physical networks and a router between them, currently using some kind of private address range. Later they get "real" Internet access, so rather than renumbering all of my hosts I simply give them two addresses so that the private addresses go on working and each host also has public addresses. No NAT, just a different internal idea of addresses.
Of course, if there's no private address range available this isn't an option, and so I would have to renumber. That would be annoying. This is why I'm curious as to why the private address range in IPv6 is being deprecated.
Not all networks are on the Internet.
Sure, I know if they're not on the Internet then technically they can use any IP range and probably don't need the overhead of IPv6, but it's nice to play by the rules so you don't get headaches if the network ever does somehow get an Internet connection.
Even with everyone connected to the Internet, there's never going to be just one network. We're always going to have to deal with weird situations where there's some kind of bridge between an odd special network and the Internet, whether due to logistical or simply administrative reasons.
I don't use RSS (and Atom) for reading the news, I use it to monitoring posts in people's weblogs and sometimes even the comments to them if the content producer has been nice enough to make those available.
I agree that using RSS to read "real news" is like trying to read someone else's newspaper from the other end of a train car.
A possiblility is to try to reinvent the NNTP model over HTTP. Have big "super-nodes" which poll the originating feeds and store the result in some big database, and then allow users to pull down one big feed containing stuff from all of the sources they are interested in.
Of course, there'd have to be something in it for the super-nodes, and I suspect what would happen is that they would charge a nominal fee, or perhaps bundle it alongside some other, similar service. One example of this is LiveJournal, which currently distributes RSS and Atom feed content to any interested LiveJournal user via the "friends page" mechanism from a single database, so there's only one poll per hour (or so). All they need now is some kind of feed of the "friends view" and you have a special version of a feed distributor with some value-add: you get all of your LiveJournal friends' content in there too.
Bare RSS isn't set up for this since it can't support per-item source information, but Atom can do it and RSS can be extended through namespaces to contain the relevant info as long as it becomes popular enough that clients support it.
In fact, if this were to be done, it would also be useful to have an optional "intelligent poll" mode where the client tells the server a magic token it got on its last poll which the server can then use to give a delta feed rather than a fixed feed. This would have to be optional, since the CPU burn of it vs. just copying a static file to a socket would probably only be a win on big sites like Slashdot and BBC News Online.
In fact, it looks like the Atom guys already thought of all this. Check out AggregateFeeds, SuperAggregator and the overly-long PossibleHTTPExtensionForEfficientFeedTransfer entries in the Atom Wiki. I didn't read it all through in depth, but it looks like they're talking about the same thing I'm talking about.
BitTorrent is the wrong model. What you want is something more like the NNTP model, but with persistant connections rather than polling. Content producers would sign their content (to prove it hasn't been modified/faked) and push it into a Peer-to-Peer cloud. The content item then gets shoved around the cloud so that interested parties can store it.
The most efficient approach is probably to create small clouds surrounding each content source rather than one big cloud shoving everything around, so the problem just becomes handling the initial bootstrap (like a BitTorrent tracker) rather than handling the content distribution to each client individually. However, the "one big cloud" solution also has advantages. It means that eventually people will be able to push in content which isn't from any website at all and have others subscribe to it. Clients would watch all passing data and snag what they are interested in. Replies to articles wouldn't go back through the originating server, they'd just get pushed around the cloud with a reply marker and clients would be able to produce a threaded display much as a USENET newsreader does.
Of course, this all needs clever swarming/distribution algorithms to avoid swamping all users with loads of data they don't care in the slightest about, but there's plenty of prior art out there to base it on.
What about if I have two private networks and I want to route between them? What IPv6 range should I use for the addresses that both networks can see?
I must admit I don't really play N64 games. I toyed with Project64 a long time ago on a different system and put my lack of success down to the limitations of that box rather than to Project64 itself.
Keeping the sound in sync is a hard thing for an emulator to do since it must, of course, be running at exactly the same speed as the system it is emulating to keep the sound from being choppy. When dealing with this issue in the past on older systems I've often just turned off the sound, since it's rarely necessary anyway and I can just put some music on my stereo system or whatever. I know this isn't really a solution, but at least you still get to play the games if it's only sound that is broken.
Buggy emulation (leading to locks and crashes) is, of course, not possible to work around. You just have to play a different game and wait for the emulator developers to fix it. I'm sad to say that my TV box runs Windows XP Home right now so I can't comment on emulator performance in Linux. This choice was driven by the lack of decent linux support for the TV chip on my graphics card -- it'll turn it on, and I can get all sorts of interesting low-level access to the chip, but I was too lazy to tweak it to get the good picture and easy overscan switching I can get with the manufacturer's drivers and software in Windows.
As for discussing emulation: I'm not really scared of Nintendo here. If they're going to go after anyone, they'll be going after the emulator developers and not the users. (The grey area about the copying of the games to ROM images notwithstanding.)
My standard phone line (in the UK) isn't included in the telephone directory either. It's an option available to all users of the phone system here, and my telco doesn't include customers by default. This is actually probably due more to the administrative issues of passing customer details over to BT for the directory, but it suits me anyway.
Isn't being excluded from the telephone directory allowed in the US?
Judging by ActiveState's Visual Perl (and the related products for Python and XSLT), Visual Studio.NET allows you to plug in support for new languages.
It might be worth investigating how hard it would be to adapt the ASP.NET stuff into a PHP IDE which works identically to ASP.NET's, or if necessary re-implement parts of it so that PHP has a comparable Visual Studio interface.
I don't use Visual Studio or ASP.NET, so I've no idea what the IDE is like, but I assume it can't be that special since, after all, we're just talking about website templates and backend code here, right?
I remember when J2ME first became popular and I heard 12 and 13 year olds sitting in the street talking about how their phones support "Java" and how that means that they can play games on it.
Similar things happened several times, and most of the time it was clear that none of them really knew what Java was or how it related to games or phones, it's just a name for a thing the phone does like "polyphonic ringtones" or "WAP".
Also, I would have trouble buying "Java Powered" unless the phone's core software was running in a JVM. "Runs trivial little games and applications using Java" isn't the same as "Wouldn't work at all without Java".
The first few generations of Microsoft's wizards were closer to Apple Guide. I can't remember which app did it first, but the one I dealt with most was an old version of Microsoft Publisher, since my family liked to use it to produce flashy layouts for homework assignments and the like.
The wizards in Publisher would ask you questions and then, once the wizard is complete, it would give you the option of either just doing whatever you wanted to do, or doing it slowly, simulating selections on the menus and dialog boxes so that you could see what the program was doing to complete the task.
Of course, having the user do it for himself is probably a much better learning aid, but this at least was a reasonable compromise between getting the job done efficiently the first time and letting the user know how to do it "the normal way" in the future.
Sadly, this feature was phased out somewhere between Publisher 98 for Windows 3 and the Win32 version, and all of the other Microsoft applications lost it too. Now Microsoft is wizard-mad, and a lot of things in Windows can only be done with wizards: they are the means by which you do things, rather than a teacher to help you learn the long way. In some cases, where the list of tasks is by nature very linear, this works. In other cases, I often just wish it'd give me a dialog box containing all of the relevant options with sensible defaults and just let me pick out what I need to change.
I would argue that in a well-designed application the backend should have little or no relationship with the UI. The backend should provide completely generic access to retrieve or do whatever the app is supposed to do. The UI should then talk to the backend in response to user commands.
Before you cry foul note that I'm not talking about a one-to-one correspondance between the user interface "commands" and the backend API. All I am saying is that the code to handle the user interface can do whatever is necessary to allow the intuitive interface to do what it needs to do as a sequence of backend API calls and some (potentially quite complicated) glue code.
Mixing in the UI with the backend will just cause problems later when things need to change in the backend or the UI. Keeping them cleanly separated, with the backend clean and general, means that theoretically you could strip off the entire UI and put a different one in its place, or even have several different user interfaces all calling the same backend API, providing a Gtk+ interface, a Win32 interface and an OS X interface, and even web and command line interfaces.
It doesn't matter what you do first as long as each layer is clearly separated from the other layers except for a carefully-interfaced tree relationship. (The UI depends on the backend, the backend depends on the underlying data source)
What I sometimes call "VB design" (after Visual Basic), where the GUI *is* the application and the backend depends on the UI, is one of the worst design methodologies ever attempted.
Of course, all of this is hypothetical. Most application developers don't have the patience to keep the backend clean and generic, and inevitably UI-oriented junk creeps in over time... or worse, they spend ages designing the back end and then have no energy left for the UI and it just ends up being a launcher for API functions. Simply saying "do the UI first" isn't enough, though. I say do them in whatever order you like but put the required amount of effort into all parts of the application, not just the backend, and keep clear in your mind what is interface and what is backend.
I like to think I've got enough theory in my head to have a good whack at user-interface design, but of course I'm not going to claim to be an expert. There are two main skills we need for user interfaces in open source software:
The second of these is the easier of the two, and I think most people can make some constructive comments about the pros and cons of a user interface designed by someone else. The first item, however, is the hardest part. To start from scratch like that requires quite a lot of background, and while some developers make a reasonable stab at it, usually by responding to how other developers handled a similar situation, that can't work for all cases.
Until such a time when we have qualified UI engineers contributing to open source projects, I think it's useful to increase the feedback between the two tasks above. The original developer uses some simple UI background to design an initial interface, then throw it to other developers and interested users and invite feedback on the interface specifically. The developers, in their role as developers, will probably point out some inconsistancies with the simple rules they have learnt, but the developers can also take the role of users and see what they find hard to do in the software.
Once that is fed back, the user interface can be refined just like the rest of the software until it's good to go. This refinement process works for the innards of the software, where perhaps the set of people able to make good comments is smaller, but everyone can have a point of view on a user interface because everyone knows what they are trying to do and what's obstructing them from doing it. Of course, we have to remember not to go overboard as some goals will be more "common" than others, but we make decisions like this in software design every day so applying similar priorities to the UI suggestions should come naturally to any seasoned open-source developer.
All my PC-connected-to-TV is used for is emulating old consoles. I just have a couple of USB control pads and some nice emulators, some crappy software to provide an easy interface to it, and I can sit in my living room and play Super Mario Kart, Streets of Rage or one of many more games with my friends without having to have fifteen consoles all over the place.
The PC isn't good enough to emulate an X-Box, Playstation2 or a Game Cube but it can handle basically everything before that. Most games since the Playstation have been pretty useless and/or available on PC anyway...