However, I'm not married to the GPL. There are some things that I want to be able to put in the public domain or BSD license, and some that should be LGPL. Furthermore, there are people (very prominent open source folks) who do not like using the GPL and do not use it.
TrollTech's licensing scheme does not allow that.
For a random minor library, this would not produce much of a stir. However, TrollTech is trying to maintain license control over what it tried to push as the standard widget set for Unix. To me, this is the next closest thing to trying to use libc as a lever (since this is fundamental for any standard GUI app). We already went through far too much pain with Motif to want to do it all over again. It just isn't worth hassling with.
Furthermore, TrollTech no longer produces a GPLed Windows Qt version. You want to make cross-platform software (which is free using GTK+ or Swing or whathaveyou), you need to purchase a license. Again, many folks don't care, but some do.
A lot of folks take a moralistic stance -- "look, TrollTech has a right to make money *somehow*. What do you propose they do, just give everything away?" I simply can't accept one organization being able to use such a fundamental thing as the standard widget set on a platform as a club. If that means that we can't have a corporate-provided widget set and need to use a volunteer-produced (actually, a number of companies fund GTK+ development, so this isn't entirely true), then so be it. It's been done many times on Linux, and can be done with a widget set as well.
The sad thing is that many folks that intensely dislike Qt have no problem with KDE. KDE gets a lot of crap that really derives from the choice of Qt as a widget set. However, if you use KDE, you're stuck with Qt, so there isn't much choice.
The C vs. C++ thing is also tough. I suspect a lot of people feel some sort of strange allegiance to the "traditional" Unix way, and believe C solves all problems equally well as C++ because hey, that's what Unix (and Linux, and so forth) uses. This just isn't true, of course, especially when it comes to reusability.
At one point, I would have agreed with you. However, with C++, I simply have not seen the code reuse benefits. The C++ code reuse model (and to some extent, OO in general) requires a huge amount of work, essentially doing a complete and highly detailed design before beginning any coding. If, at some point, you realize that you've made a small error and need some additional data, your changes may need to be vast and far-reaching. This was a popular design style ten years ago, but currently trendy stuff, like extreme programming involves more iteration.
Secondly, the STL is not a convincing argument with Qt, because Qt does not make any effective use of the STL, unlike, for instance, gtkmm.
Finally, while C *is* a specialized language not designed for general application development, that does not mean that C++ is particularly better. I agree that C has a number of flaws as an application language, but C++ does not fix the significant problems.
Drag and Drop has certain benefits, but there are reasons that it's never really taken over as the standard interface system.
First issue: DnD is not standardized in tasks performed in response to a given action -- it bears much in common with the right mouse button on x86 boxes before the advent of Windows 95. Suppose I drag a Word-openable document into a Word window containing an open document. Should Word open the dragged-in document? Should it embed an OLE object referencing the document? Should it attempt to import and insert the data directly into the document? When I'm typing an email in Lotus Notes, I can attach a document by using the "Attach" menu. However, if I drag a document into the email window, the document is simply embedded and appears as part of my email.
Second issue: DnD does not have an obvious keyboard equivalent in current desktop environments. While there is no law of HCI stating that every mouse-operable action must always have a keyboard equivalent, it has been informally adopted as a convention by most desktop environment GUI folks to have an equivalent whenever possible. If DnD is used to replace opening and saving, a very common activity, but no keyboard equivalent is given, many keyboard fans are going to be quite unhappy.
Third issue: current widget sets (and perhaps this was not the case on the Acorn) do not provide good default DnD behavior. Generally, I've found that features where application authors must go out of their way to provide support for the feature to work tend not to work consistently. The more work it takes to support something, the less likely it is to be supported. (The most notable exception is the "resize to fit window contents" titlebar button in MacOS -- however, this was a very obvious and blatant thing to make not work correctly.) DnD, if used as a replacement for copy-and-paste or open-and-save, must work *everywhere* to be effective. If it works in 30% of your apps, you're going to simply use the method that works in all of your apps instead. Last I looked, nobody implemented DnD globally and consistently enough for it to be worthwhile.
Fourth issue: By overloading some interface actions, DnD may be detrimental to the user. This is most irritating when working with DnD support for text. Traditional text editing states that clicking and dragging over text starts and begins extending a new selected area of text -- this is regardless of where the user clicks. DnD means that this behavior changes for text within an already selected area of text. To select a subset of an already selected area of text, the user must click once to deselect the area. I found this incredibly annoying in Mac OS System 7.5 -- DnD was not implemented consistently enough to rely upon, and it *did* impose irritating constraints on my text editing behavior.
I agree that making the directory browser and the file browser one and the same has a number of appealing benefits, though...
Inheritance alone does not cleanly solve this problem.
Think about how you'd implement this -- it can be done, but it's not quite on the order of just adding another member function. You'd need some sort of registration system to allow inserting the button at the right place. I'd probably have the constructor for the derived class toss something into a list of widgets with a callback aimed at my new method (or to be really C++, a function object) providing the "push" action for that button. At that point, you could do the same thing in C as easily as C++.
OO actually has surprisingly little to do with clean design in most places. I remember the first time I saw OO, I was enthralled (as are, I think, most people). However, then I started looking at what OO code actually did better/more cleanly/with less code in real programs than non-OO code...and didn't turn much up.
As someone else has pointed out, GTK+ uses OO design anyway, though not C++.
Normally, I don't read random, unresponded to comments late in discussion.
However, I read this one when I saw "readline completion", and was very pleased.
First, it phrased exactly my frusteration with many Linux GUI apps -- why can't the basic tab completion functionality that already exists for bash/zsh (slightly more than readline alone, FWIW) be replicated? This is a mature, well-designed interface that has been already done once. Why throw out what has already been achieved in the CLI world?
Second of all, it introduced the first really interesting and inventive browser UI idea I've seen in a while. Why *can't* text fields be maximized? This is a damned good idea -- I'm sure others have struggled with tiny text entry areas that allow one no more than a peephole into their editing environment. I should be able to kick the text entry field into a full-window mode for typing up my email/comment/message, and then be able to drop it back down to regular size.
However, the fact that the KDE file selector can do much of what I'm suggesting is not particularly useful to the current discussion, which is on what the GTK+ file selector should do.
Well...at least as far as copyright rights go, there really is no overlap.
Take the (infamous trade secret) example of the Coca-Cola recipe. A copyrighted list of ingredients exists somewhere and is owned by Coca-Cola, but it is of no particular use to Coca-Cola. It does not prevent someone from writing down their own list containing the same ingredients but presented differently. It does not take into account the fact that Coca-Cola Inc. does not want people to *implement* the recipe, which are not covered under copyright law. Both of these points are covered under trade secret law. The copyright rights granted to the company simply have nothing to do with what they want to protect.
Right, which is why I said that there's probably some equivalent for the PDS slot. There isn't always for legacy ISA, but those ISA cards required manual configuration. Mac hardware is pretty much always autodetected, and hence probably has to have some way to spit back an identifier to the machine.
Actually, I'd say that those are mostly more sensible than this one.
The submitter committed a number of grievious violations of netiquette.
* The submitter already knows part numbers. This is a Google problem. He should have already looked these up and need no help with these.
* If the submitter is unable to find part numbers, software procedures should have been tried. I'm not sure (never owned an LC-era machine) but if I wanted to know what a strange PCI card was, I'd pop it in my x86 Linux box and check/proc/pci for any information. There's probably some kind of equivalent for the LC.
* A picture is unlikely to help. Asking people to tear up their LCs for similar-looking cards is ridiculous.
* This question should, if the submitter could obtain *no* information at all themselves, then have gone to a classic Mac specific tech forum. Apple-based, one of the Usenet groups, IRC. All three should have been tried.
* In general, old hardware identification is a pretty drudge task. It's not something you ask other people to do. It's time-consuming, not particularly interesting, and a waste of time, since it's not going to be useful to other people. The kind of tech questions you want to ask (and gurus want to answer) are those that will help others as well. If you can't fix this yourself, instead of asking a quarter-million people to spend hours of skilled time solving your problem, buy a bloody used Ethernet card. I don't care who you are, you can afford it. People throw these things out.
The degeneration of Ask Slashdot is wildly frusterating to me. Ask Slashdot really is a useful feature, but it's incredibly abused. On the up side, it allows people to ask questions that require more feedback than just a poll. For example, "What is your favorite set of Google tricks?" or "What security procedures do you use for SSH key distribution?" Here we have something that will be useful and interesting to many techies, but will not be available on the Web. Furthermore, any of these are likely to produce futher conversation. This differs wildly from stories like the current one, which are of no use to anyoen but the submitter.
The other way Ask Slashdot is frequently abused is to post stories that are too uninteresting or biased to be accepted in the regular categories. Frequently, these take the form of "blah blah blah How do you feel about this? What suggestions do you have for SCO/Microsoft/etc?" This is simply not an appropriate forum for stories like this. If they aren't interesting enough for the proper categories, they aren't interesting enough to be on Slashdot.
The editors are also at fault for allowing so many poor Ask Slashdots to slip by.
Sure, and there's a module for LUFS to support GNOME-VFS. However, this is awfully ugly. In the case of KDE, it means supporting C++ and the KDE types and model, and in the case of GNOME, the GNOME types and model. It's a lot of complexity, overhead and potential breakability getting added. Plus, do you want the additional dependencies? Do you really want to have to install GNOME for WebDAV support and KDE for SFTP support?
Will i go buy tee.shirt.yellow.minnesota.walmart and have the register go look up the RFID and price information? That would seem backwards.
Right. He's just saying that we should use DNS, as it's lightweight and globally used, to distribute universal identifiers other than domain names -- in this case, RFIDs, which would only forward-resolve. Useful for scanning a product and finding out what it is.
My guess is that there'd just be a new TLD for each, given that RFIDs (I assume) and UPC codes are universal. I believe there's some sort of central registrar for these -- DNS could be used for just distribution, of the data and not decentralization of administration, as it currently is for domain names.
I'm not entirely sure that this is a good idea. The main benefits of DNS are that there's a lot of infrastructure to support it, firewalls don't block it (or at least a proxy is provided), and it's pretty lightweight. However, it has some significant drawbacks for the usages involved. DNS is not a secure system. It was not designed to be secure -- spoofing responses is not a huge deal. We've learned to build systems to work around the insecurities -- ssh caches host keys to avoid DNS cache poisoning, for instance -- but this is a really serious problem when it comes to RFID and UPC. If I can start spoofing things so that the wrong items are looked up, God only knows what I can do to commercial and POS systems that use such a system. Very bad juju that cannot be worked around with our existing systems.
Second of all, DNS activity tends to be sporadic. Very sporadic. There might be one lookup, ten mintues, and then a couple of lookups. There are also a *vast* number of clients relative to the number of DNS servers required to handle them. DNS is designed around these kind of performance demands. I'm not sure that most UPC and RFID use is like this. Generally, a POS system with a scanner is scanning a fair number of things at a good rate -- at the very least, you're likely to have bursts of steady scanning for perhaps ten requests or so. Thus, the cost of establishing a connection and then letting that connection go away after no requests have gone away for a bit is greatley lessened. Given this, the security and reliability benefits of a connection-oriented system like TCP become more appealing. Furthermore, you generally know ahead of time that you are going to be scanning -- e.g. the cashier is at the register and ringing up an order. This means that you may not even need to undergo the initial latency. There are also perhaps ten registers at a given grocery store. These ten registers supply a huge number of people, and given the money they pull in, it's not a huge financial cost to have one server that provides for these ten machines. UDP allows for lower overhead when servicing a vast number of clients.
I'd rather go with a more powerful protocol running over TCP and tunneled in SSL.
* Saving favorite locations is an add-on feature for a lot of file selectors. This is easy to add, and might be worth considering. This is not GNOME-specific.
* Showing the last N locations used with this app or globally might be a nice (potentially optional, for privacy reasons) feature.
* We still don't have tab completion at the level of bash convenience. I'd like to be able to partially type a relative and absolute path without blowing away the default filename (particularly an issue for, say, galeon). If this requires a "filename" field above and in addition to the "path" field, so be it. UNIX folks like the flexibility of bash. Previous GTK+ file selectors have not had this.
KDE has an awesome file selector - as I go down the list of PDF files, and choose one, a preview window shows the PDF scaled, right there in the selection windo
You're confusing GNOME and GTK+.
The discussion is about the GTK+ file selector, which is analogous to the Qt, rather than the KDE file selector.
So a next-generation save/open box should include comprehensive network protocol support.
With all due respect, I think that this is a really, really awful idea. Unfortunately, Microsoft has traditionally taken this approach (for political, not engineering reasons). The KDE project, which takes a very Windows-like approach to a number of architecture decisions, copied their approach, and GNOME has come uncomfortably close.
The reason why I'm not a fan of implementing network transparency at the KIOSlave or GNOME-VFS or whatnot layers is that this sort of functionality is *not* KDE or GNOME or whathaveyou specific. It just isn't part of the desktop environment. It should be implemented at a lower level, so that *all* programs running on the machine can take advantage of the functionality. There are a couple of projects that do this -- take a look at LUFS for a proper (IMHO, of course) implementation of what you're asking for.
Really, almost the entire GUI paradigm has been copied around by all parties involved. Some of this is because it works pretty well, and some of it because people get familiar with working a particular way and don't want to change. Ever since the original Mac, the desktop user interface hasn't changed all that much.
I think this is a good thing. It'd be terribly annoying if UI ideas were patented and we had to have a bunch of half-assed environments.
Yes, game developers (actors) are also worked to death, and make much less money than the publishers (studios) in the Golden Age did.
I think that the rate of technological advancement is part of why game productions are still relatively (well, compared to a movie) small. If you have processors doubling in power every 18 months, video resolutions climbing, and an even faster rate of improvement on video chipsets, and unforseen standard-of-gameplay improvements increasing you simply cannot afford to spend ages producing your game. Gargantuan productions aren't as survivable as fast, more quickly released productions.
It's pretty simple. The value of a stock is not directly tied (well, except perhaps via dividends or a company actually dissolving) to how well a company is doing. The only thing that matters is predicting what other people will do before they do it. In this case, a lot of people bought SCOX. As long as traders manage to divest themselves of SCOX shares before SCOX actually goes under, it doesn't matter whether SCOX is doing poorly as a company.
Folks who sold SCOX short can just wait until SCOX goes under.
While free markets make a lot of sense, capitalism (the investing of funds in companies, at least in its modern form) has too much tendancy to cause splits between the interest of a company and the interest of its management.
While SCO is decidedly in the wrong (actually, I haven't seen a single significant point in which they've been in the right), trade secrets and copyrights are entirely different beasts.
No. It'd just give SCO ammunition. Furthermore, the SCO code is *awfully* unlikely to have any current practical value to Linux kernel developers, as many hackers have repeatedly pointed out. I suspect LKML folks wouldn't touch SCO code with a ten foot pole.
If you wanted more reviews, why aren't you searching for (without the quotes) "sony dsc-f828 review"? I get a nice list of reviews -- more than I care to read, at least. I mean, if you asked a human for results containing just "sony dsc-f828", I'm not sure they'd get you just reviews either -- I'd return the manufacturer's page first, then probably a review or two, and then probably an amazon.com purchasing link. Not that far from what you got back. If you want to purchase the camera, tack "buy" onto the end. Not that hard.
Really? I've been pretty disappointed with alltheweb as a general search engine, but they do have a larger media index than Google and do maintain an FTP search engine. So if I'm looking for pictures of something or want to look for a file on public FTP archives, to them I go...but otherwise, Google.
Slashdot Mirror
Doesn't the fact that a new Linux file selector dialog box becomes headline news really illustrate the state of the Linux GUI?
Apple has generally been considered a pretty good pathblazer when it comes to UI.
Apple was, not very long ago, in the news with OS X's new file selector.
So, no, I don't consider having a change in your file selector imply that your UI is behind.
That being said, the old GTK+ file selector really did rather suck.
As it happens, I like to GPL my code.
However, I'm not married to the GPL. There are some things that I want to be able to put in the public domain or BSD license, and some that should be LGPL. Furthermore, there are people (very prominent open source folks) who do not like using the GPL and do not use it.
TrollTech's licensing scheme does not allow that.
For a random minor library, this would not produce much of a stir. However, TrollTech is trying to maintain license control over what it tried to push as the standard widget set for Unix. To me, this is the next closest thing to trying to use libc as a lever (since this is fundamental for any standard GUI app). We already went through far too much pain with Motif to want to do it all over again. It just isn't worth hassling with.
Furthermore, TrollTech no longer produces a GPLed Windows Qt version. You want to make cross-platform software (which is free using GTK+ or Swing or whathaveyou), you need to purchase a license. Again, many folks don't care, but some do.
A lot of folks take a moralistic stance -- "look, TrollTech has a right to make money *somehow*. What do you propose they do, just give everything away?" I simply can't accept one organization being able to use such a fundamental thing as the standard widget set on a platform as a club. If that means that we can't have a corporate-provided widget set and need to use a volunteer-produced (actually, a number of companies fund GTK+ development, so this isn't entirely true), then so be it. It's been done many times on Linux, and can be done with a widget set as well.
The sad thing is that many folks that intensely dislike Qt have no problem with KDE. KDE gets a lot of crap that really derives from the choice of Qt as a widget set. However, if you use KDE, you're stuck with Qt, so there isn't much choice.
The C vs. C++ thing is also tough. I suspect a lot of people feel some sort of strange allegiance to the "traditional" Unix way, and believe C solves all problems equally well as C++ because hey, that's what Unix (and Linux, and so forth) uses. This just isn't true, of course, especially when it comes to reusability.
At one point, I would have agreed with you. However, with C++, I simply have not seen the code reuse benefits. The C++ code reuse model (and to some extent, OO in general) requires a huge amount of work, essentially doing a complete and highly detailed design before beginning any coding. If, at some point, you realize that you've made a small error and need some additional data, your changes may need to be vast and far-reaching. This was a popular design style ten years ago, but currently trendy stuff, like extreme programming involves more iteration.
Secondly, the STL is not a convincing argument with Qt, because Qt does not make any effective use of the STL, unlike, for instance, gtkmm.
Finally, while C *is* a specialized language not designed for general application development, that does not mean that C++ is particularly better. I agree that C has a number of flaws as an application language, but C++ does not fix the significant problems.
Mmmmff.
Drag and Drop has certain benefits, but there are reasons that it's never really taken over as the standard interface system.
First issue: DnD is not standardized in tasks performed in response to a given action -- it bears much in common with the right mouse button on x86 boxes before the advent of Windows 95. Suppose I drag a Word-openable document into a Word window containing an open document. Should Word open the dragged-in document? Should it embed an OLE object referencing the document? Should it attempt to import and insert the data directly into the document? When I'm typing an email in Lotus Notes, I can attach a document by using the "Attach" menu. However, if I drag a document into the email window, the document is simply embedded and appears as part of my email.
Second issue: DnD does not have an obvious keyboard equivalent in current desktop environments. While there is no law of HCI stating that every mouse-operable action must always have a keyboard equivalent, it has been informally adopted as a convention by most desktop environment GUI folks to have an equivalent whenever possible. If DnD is used to replace opening and saving, a very common activity, but no keyboard equivalent is given, many keyboard fans are going to be quite unhappy.
Third issue: current widget sets (and perhaps this was not the case on the Acorn) do not provide good default DnD behavior. Generally, I've found that features where application authors must go out of their way to provide support for the feature to work tend not to work consistently. The more work it takes to support something, the less likely it is to be supported. (The most notable exception is the "resize to fit window contents" titlebar button in MacOS -- however, this was a very obvious and blatant thing to make not work correctly.) DnD, if used as a replacement for copy-and-paste or open-and-save, must work *everywhere* to be effective. If it works in 30% of your apps, you're going to simply use the method that works in all of your apps instead. Last I looked, nobody implemented DnD globally and consistently enough for it to be worthwhile.
Fourth issue: By overloading some interface actions, DnD may be detrimental to the user. This is most irritating when working with DnD support for text. Traditional text editing states that clicking and dragging over text starts and begins extending a new selected area of text -- this is regardless of where the user clicks. DnD means that this behavior changes for text within an already selected area of text. To select a subset of an already selected area of text, the user must click once to deselect the area. I found this incredibly annoying in Mac OS System 7.5 -- DnD was not implemented consistently enough to rely upon, and it *did* impose irritating constraints on my text editing behavior.
I agree that making the directory browser and the file browser one and the same has a number of appealing benefits, though...
No.
Inheritance alone does not cleanly solve this problem.
Think about how you'd implement this -- it can be done, but it's not quite on the order of just adding another member function. You'd need some sort of registration system to allow inserting the button at the right place. I'd probably have the constructor for the derived class toss something into a list of widgets with a callback aimed at my new method (or to be really C++, a function object) providing the "push" action for that button. At that point, you could do the same thing in C as easily as C++.
OO actually has surprisingly little to do with clean design in most places. I remember the first time I saw OO, I was enthralled (as are, I think, most people). However, then I started looking at what OO code actually did better/more cleanly/with less code in real programs than non-OO code...and didn't turn much up.
As someone else has pointed out, GTK+ uses OO design anyway, though not C++.
Thank you.
Normally, I don't read random, unresponded to comments late in discussion.
However, I read this one when I saw "readline completion", and was very pleased.
First, it phrased exactly my frusteration with many Linux GUI apps -- why can't the basic tab completion functionality that already exists for bash/zsh (slightly more than readline alone, FWIW) be replicated? This is a mature, well-designed interface that has been already done once. Why throw out what has already been achieved in the CLI world?
Second of all, it introduced the first really interesting and inventive browser UI idea I've seen in a while. Why *can't* text fields be maximized? This is a damned good idea -- I'm sure others have struggled with tiny text entry areas that allow one no more than a peephole into their editing environment. I should be able to kick the text entry field into a full-window mode for typing up my email/comment/message, and then be able to drop it back down to regular size.
Read the earlier response to my post.
However, the fact that the KDE file selector can do much of what I'm suggesting is not particularly useful to the current discussion, which is on what the GTK+ file selector should do.
Well...at least as far as copyright rights go, there really is no overlap.
Take the (infamous trade secret) example of the Coca-Cola recipe. A copyrighted list of ingredients exists somewhere and is owned by Coca-Cola, but it is of no particular use to Coca-Cola. It does not prevent someone from writing down their own list containing the same ingredients but presented differently. It does not take into account the fact that Coca-Cola Inc. does not want people to *implement* the recipe, which are not covered under copyright law. Both of these points are covered under trade secret law. The copyright rights granted to the company simply have nothing to do with what they want to protect.
Right, which is why I said that there's probably some equivalent for the PDS slot. There isn't always for legacy ISA, but those ISA cards required manual configuration. Mac hardware is pretty much always autodetected, and hence probably has to have some way to spit back an identifier to the machine.
Actually, I'd say that those are mostly more sensible than this one.
/proc/pci for any information. There's probably some kind of equivalent for the LC.
The submitter committed a number of grievious violations of netiquette.
* The submitter already knows part numbers. This is a Google problem. He should have already looked these up and need no help with these.
* If the submitter is unable to find part numbers, software procedures should have been tried. I'm not sure (never owned an LC-era machine) but if I wanted to know what a strange PCI card was, I'd pop it in my x86 Linux box and check
* A picture is unlikely to help. Asking people to tear up their LCs for similar-looking cards is ridiculous.
* This question should, if the submitter could obtain *no* information at all themselves, then have gone to a classic Mac specific tech forum. Apple-based, one of the Usenet groups, IRC. All three should have been tried.
* In general, old hardware identification is a pretty drudge task. It's not something you ask other people to do. It's time-consuming, not particularly interesting, and a waste of time, since it's not going to be useful to other people. The kind of tech questions you want to ask (and gurus want to answer) are those that will help others as well. If you can't fix this yourself, instead of asking a quarter-million people to spend hours of skilled time solving your problem, buy a bloody used Ethernet card. I don't care who you are, you can afford it. People throw these things out.
The degeneration of Ask Slashdot is wildly frusterating to me. Ask Slashdot really is a useful feature, but it's incredibly abused. On the up side, it allows people to ask questions that require more feedback than just a poll. For example, "What is your favorite set of Google tricks?" or "What security procedures do you use for SSH key distribution?" Here we have something that will be useful and interesting to many techies, but will not be available on the Web. Furthermore, any of these are likely to produce futher conversation. This differs wildly from stories like the current one, which are of no use to anyoen but the submitter.
The other way Ask Slashdot is frequently abused is to post stories that are too uninteresting or biased to be accepted in the regular categories. Frequently, these take the form of "blah blah blah How do you feel about this? What suggestions do you have for SCO/Microsoft/etc?" This is simply not an appropriate forum for stories like this. If they aren't interesting enough for the proper categories, they aren't interesting enough to be on Slashdot.
The editors are also at fault for allowing so many poor Ask Slashdots to slip by.
Sure, and there's a module for LUFS to support GNOME-VFS. However, this is awfully ugly. In the case of KDE, it means supporting C++ and the KDE types and model, and in the case of GNOME, the GNOME types and model. It's a lot of complexity, overhead and potential breakability getting added. Plus, do you want the additional dependencies? Do you really want to have to install GNOME for WebDAV support and KDE for SFTP support?
Will i go buy tee.shirt.yellow.minnesota.walmart and have the register go look up the RFID and price information? That would seem backwards.
Right. He's just saying that we should use DNS, as it's lightweight and globally used, to distribute universal identifiers other than domain names -- in this case, RFIDs, which would only forward-resolve. Useful for scanning a product and finding out what it is.
My guess is that there'd just be a new TLD for each, given that RFIDs (I assume) and UPC codes are universal. I believe there's some sort of central registrar for these -- DNS could be used for just distribution, of the data and not decentralization of administration, as it currently is for domain names.
I'm not entirely sure that this is a good idea. The main benefits of DNS are that there's a lot of infrastructure to support it, firewalls don't block it (or at least a proxy is provided), and it's pretty lightweight. However, it has some significant drawbacks for the usages involved. DNS is not a secure system. It was not designed to be secure -- spoofing responses is not a huge deal. We've learned to build systems to work around the insecurities -- ssh caches host keys to avoid DNS cache poisoning, for instance -- but this is a really serious problem when it comes to RFID and UPC. If I can start spoofing things so that the wrong items are looked up, God only knows what I can do to commercial and POS systems that use such a system. Very bad juju that cannot be worked around with our existing systems.
Second of all, DNS activity tends to be sporadic. Very sporadic. There might be one lookup, ten mintues, and then a couple of lookups. There are also a *vast* number of clients relative to the number of DNS servers required to handle them. DNS is designed around these kind of performance demands. I'm not sure that most UPC and RFID use is like this. Generally, a POS system with a scanner is scanning a fair number of things at a good rate -- at the very least, you're likely to have bursts of steady scanning for perhaps ten requests or so. Thus, the cost of establishing a connection and then letting that connection go away after no requests have gone away for a bit is greatley lessened. Given this, the security and reliability benefits of a connection-oriented system like TCP become more appealing. Furthermore, you generally know ahead of time that you are going to be scanning -- e.g. the cashier is at the register and ringing up an order. This means that you may not even need to undergo the initial latency. There are also perhaps ten registers at a given grocery store. These ten registers supply a huge number of people, and given the money they pull in, it's not a huge financial cost to have one server that provides for these ten machines. UDP allows for lower overhead when servicing a vast number of clients.
I'd rather go with a more powerful protocol running over TCP and tunneled in SSL.
Yup.
Other points to consider:
* Saving favorite locations is an add-on feature for a lot of file selectors. This is easy to add, and might be worth considering. This is not GNOME-specific.
* Showing the last N locations used with this app or globally might be a nice (potentially optional, for privacy reasons) feature.
* We still don't have tab completion at the level of bash convenience. I'd like to be able to partially type a relative and absolute path without blowing away the default filename (particularly an issue for, say, galeon). If this requires a "filename" field above and in addition to the "path" field, so be it. UNIX folks like the flexibility of bash. Previous GTK+ file selectors have not had this.
KDE has an awesome file selector - as I go down the list of PDF files, and choose one, a preview window shows the PDF scaled, right there in the selection windo
You're confusing GNOME and GTK+.
The discussion is about the GTK+ file selector, which is analogous to the Qt, rather than the KDE file selector.
So a next-generation save/open box should include comprehensive network protocol support.
With all due respect, I think that this is a really, really awful idea. Unfortunately, Microsoft has traditionally taken this approach (for political, not engineering reasons). The KDE project, which takes a very Windows-like approach to a number of architecture decisions, copied their approach, and GNOME has come uncomfortably close.
The reason why I'm not a fan of implementing network transparency at the KIOSlave or GNOME-VFS or whatnot layers is that this sort of functionality is *not* KDE or GNOME or whathaveyou specific. It just isn't part of the desktop environment. It should be implemented at a lower level, so that *all* programs running on the machine can take advantage of the functionality. There are a couple of projects that do this -- take a look at LUFS for a proper (IMHO, of course) implementation of what you're asking for.
Really, almost the entire GUI paradigm has been copied around by all parties involved. Some of this is because it works pretty well, and some of it because people get familiar with working a particular way and don't want to change. Ever since the original Mac, the desktop user interface hasn't changed all that much.
I think this is a good thing. It'd be terribly annoying if UI ideas were patented and we had to have a bunch of half-assed environments.
Yes, game developers (actors) are also worked to death, and make much less money than the publishers (studios) in the Golden Age did.
I think that the rate of technological advancement is part of why game productions are still relatively (well, compared to a movie) small. If you have processors doubling in power every 18 months, video resolutions climbing, and an even faster rate of improvement on video chipsets, and unforseen standard-of-gameplay improvements increasing you simply cannot afford to spend ages producing your game. Gargantuan productions aren't as survivable as fast, more quickly released productions.
It's pretty simple. The value of a stock is not directly tied (well, except perhaps via dividends or a company actually dissolving) to how well a company is doing. The only thing that matters is predicting what other people will do before they do it. In this case, a lot of people bought SCOX. As long as traders manage to divest themselves of SCOX shares before SCOX actually goes under, it doesn't matter whether SCOX is doing poorly as a company.
Folks who sold SCOX short can just wait until SCOX goes under.
While free markets make a lot of sense, capitalism (the investing of funds in companies, at least in its modern form) has too much tendancy to cause splits between the interest of a company and the interest of its management.
Seriously -- I mean, that's a new laptop for every two faxes. A fax machine might be an excellent investment.
While SCO is decidedly in the wrong (actually, I haven't seen a single significant point in which they've been in the right), trade secrets and copyrights are entirely different beasts.
No. It'd just give SCO ammunition. Furthermore, the SCO code is *awfully* unlikely to have any current practical value to Linux kernel developers, as many hackers have repeatedly pointed out. I suspect LKML folks wouldn't touch SCO code with a ten foot pole.
If you wanted more reviews, why aren't you searching for (without the quotes) "sony dsc-f828 review"? I get a nice list of reviews -- more than I care to read, at least. I mean, if you asked a human for results containing just "sony dsc-f828", I'm not sure they'd get you just reviews either -- I'd return the manufacturer's page first, then probably a review or two, and then probably an amazon.com purchasing link. Not that far from what you got back. If you want to purchase the camera, tack "buy" onto the end. Not that hard.
Really? I've been pretty disappointed with alltheweb as a general search engine, but they do have a larger media index than Google and do maintain an FTP search engine. So if I'm looking for pictures of something or want to look for a file on public FTP archives, to them I go...but otherwise, Google.
I thought that yahoo used to use Inktomi, but switched to Google at some point.
Noise detection might be interesting. I didn't think of that.
The leak is awfully slow, though. I really doubt that they're going to be able to pick it up with smoke.