/agreed. > 50% protein by weight. It's practically a super food. Now, I've got to wonder how palatable it is. I like seaweed. Seems like it should be ok.
Re:A lot of stuff in Gtk is replacing Gnome widget
on
GTK 2.6.0 Released
·
· Score: 3, Informative
Much of the motivation on the devel mailing lists seemed to be oriented around the idea that the gnome libraries had things in them that weren't quite ready for the gtk/glib guys to commit to supporting in the API-stable 2.x series forever. So the code was put into GNOME libraries to get GNOME apps out the door. When implementations and APIs for things that are generally useful to people doing GTK-only stuff got clean enough for everyone concerned, then they got picked up.
Unfortunately, the list of dependencies isn't really broken out like that. Individual build scripts (like jhbuild, for instance) have that information included, at least for the gnome dependencies. If you're looking to build releases, garnome might be worth looking at as well.
GNOME users have done a lot of weird bashing, as have KDE users. GNOME and KDE developers (particular of the WMs and other framework components) tend not to be so flakey, though.
IMHO, choice is stupid if you can't maintain it. One of the more convincing arguments that I've seen during the public formulation of GNOME 2.0's goals is the idea that umpteen million configuration combinations are a bad idea if only a small subset are frequently used. The ones that get used are the ones that get tested. Weird combinations get bugs that nobody knows about in advance since you can't test them. Weird configuration items turn into code bloat for too many special cases.
Now, the GNOME developers are human too. It seems to me that they had to learn this through hard experience, and make a priority call on what's important to them. Software requirements analysis is the process here - design the software to solve specific requirements, and cut out the things that waste too much effort.
So yeah - I think the GNOME guys are getting it right. So what if they've changed their tune - is it better to continue perpetuating a mistake?
But in this case, which of their customers are likely to bite? It's like their marketing team went off on a mission to solve a problem that doesn't exist - who exactly in the set of customers developing with Java is going to be deluded by the version number jump?
Here's a problem with peer-to-peer from the bottom up, at least in wireless. Which "joe user" with a cell phone wants to use up his meager battery life to help another peer transmit along?
Most cell phones are off 99% of the time, and only turn on a few tens of milliseconds every second or so to see if a call is coming in. If your handset is on to help someone else establish a connection, your battery drains as well as theirs. Any kind of ad-hoc network would seem to be completely inefficient in terms of power management.
This has been the case for cell phones for some time - if you purchase a phone with a contract, your initial investment for the handset itself is subsidized by the contract. It's the service that you pay for.
Simple hardware platforms don't lend themselves to incoming revenue. PC's have not been simple for a long time - RAM, disk, video cards, new LAN, USB stuff, etc., but there's got to be a business case for simpler PCs. Selling an expandable PCI chassis to my Dad and 99% of corporate and home users is a waste of resources. Instead, get the price down with a one-size-fits-all product, and then sell him something (service) that turns into a revenue stream...
Maybe Linux distro's for desktop use needs quality control? It's half way through 2004, and the current batch of distros (bsd included) are configuration messes. WTF happened?
It's really a function of the product's focus, and the resources the company can bring to bear on it. The majority of Red Hat's QA is focused on the product that they get paid for, RHEL. Fedora isn't bringing in any money, so it gets a lot less. If you keep in mind that Fedora Core is basically dogfood to provide interim releases of the stuff that goes into RHEL, and shake out early issues BEFORE paying QA to do work that the community (i.e., not necessarily the reviwer) is going to do for free.
I'm not up on VoIP protocols, but the codecs used for GSM and CDMA protocols use anywhere from 9.6kbps to 14.4kbps, IIRC. Is VoIP doing something else (say, to make up for the lack of a circuit?)
Wait till your voicemail starts filling up with spammer ads. Telemarketers apparently have no real incentive to leave a message, but I can guarantee that spammers with free access to your voice mail will ownz it the same way they do your INBOX.
From the FAQ: The driver is based on a binary HAL...
So you'll likely have this problem with any newer distribution using kernel 2.6 until the driver gets brought up to 2.6 (assuming it hasn't already, I don't know for sure...)
FWIW, having worked at a small US company (just as cool a place as described by the parent poster to your message), and having watched it grow into a unit of a big US company, it's basically the same thing.
Big company == big money, at which point people get more uptight - no ifs, ands, or buts about it.
Yeah - he and Nick both missed the point there. GConf is just a pref management system used (in this case) to give people who really care access to an obscure preference.
Now, any particular user might disagree that making browse mode the default is obscure, but the Nautilus developers purposely decided that it was. They purposely didn't write a UI for it, but left the GConf key in for the same sorts of people who get bent out of shape if they can't pick obscure window manager settings like focus-follows-train or whatever.
You sure about that? On my Fedora 1 box, the default gnome menu runs printconf-gui, which is part of the redhat-config-printer package. (rpm -qf `which printconf-gui`)
Pat Cadigan wrote some stories where a major plot premise is that anything that happens in a virtual online world has no legal bearing in the outside world. No censorship, no legally binding contracts, nada. Then she explores the idea. Check out 'Tea from an Empty Cup' and 'Dervish is Digital' - both are worth a read.
Yeah, and if that's not enough space, you can bzip2 the text and that'll probably do it, and get obfuscation out of it to boot (you know, like they did last time).
Except, of course, that while your dragging your folder a few inches to add it to the dock, and maybe wasting time mousing over a few in the dock to figure out which one is the one you want for any given app your using, the rest of us (using OS X) just open a file selector with apple-S and save the file with enter.
Perhaps. Although I have no problem telling the person on the other end of the hands-free kit that I'm driving, and I regularly ignore them as traffic dictates. Sure, it's more distracting, but by how much? I'd love to see a study that addresses that specific point. Not sure if it can be quantified, but it's the sort of thing that would get me to shut up, pun intended.
Please don't read this as a flame - but I'm going to be blunt. I don't have much sympathy for you using a laptop to get at GPS information. Unless you've got a great solid mount holding the laptop in a position where you can quickly move your eyes between it and the road, and a touch screen interface or some easy to hit buttons, it's unsafe to drive and use it at the same time, period.
The law doesn't seem to be overly broad in this case, for what it's worth, the law does permit the use of "installed" navigational devices, which presumably don't have the above mentioned problems. So your investment in unsafe equipment is wasted, but at least you're safer.
That said, I agreed with the rest of your post. The U.S. bashing was uncalled for.
It doesn't matter how quickly you can context switch if your eyes aren't on the road when something happens in front of you.
As long as a driver is using a handsfree kit and speech recognition or steering-wheel mounted controls, a cell phone's fine, but only under those conditions. If you can reduce the use of the cell phone to an activity like talking to someone in the passenger seat or back seat, with no other distractions, your in good shape. But as soon as hands start coming off the wheel, or eyes migrate to the LCD screen on the handset instead of the road, you (and everyone aroung you) has got a problem.
So, leaving aside issues of whether or not this is a good idea, are states' rights being encroached upon with this idea? States currently license engineers as they feel its necessary - why would software require federal licensing? Engineering is engineering, whether your twiddling bytes or blocks.
When talking about existing solutions, Doran wrote:
Most alternatives would have significantly swelled the ROM container size requirement or the motherboard support overhead requirement or had licensing, IP or other impediments to deployment into the wider industry that we had no practical means to resolve.
Presumably, open firmware doesn't have IP impediments (I dunno myself). ROM size could be at issue: This page indicates that you can't get an openfirwmare image in less than 128Kbytes, and practically, 256Kbytes is probably needed. Doran stated that their interpreter was 18Kbytes uncompressed, which is a pretty measley fraction of 128Kbytes. Anyone have any idea of how big a fraction of the 128Kbytes the forth interpreter is for Open Firmware?
Granted, I'm making a few assumptions here, like, there really is a good technical reason for this, and then trying to find it. Odds are, this really is just a play for control of the standard, but it would be nice to get a little more insight into the technical differences.
Slashdot Mirror
/agreed. > 50% protein by weight. It's practically a super food. Now, I've got to wonder how palatable it is. I like seaweed. Seems like it should be ok.
Much of the motivation on the devel mailing lists seemed to be oriented around the idea that the gnome libraries had things in them that weren't quite ready for the gtk/glib guys to commit to supporting in the API-stable 2.x series forever. So the code was put into GNOME libraries to get GNOME apps out the door. When implementations and APIs for things that are generally useful to people doing GTK-only stuff got clean enough for everyone concerned, then they got picked up.
Unfortunately, the list of dependencies isn't really broken out like that. Individual build scripts (like jhbuild, for instance) have that information included, at least for the gnome dependencies. If you're looking to build releases, garnome might be worth looking at as well.
GNOME users have done a lot of weird bashing, as have KDE users. GNOME and KDE developers (particular of the WMs and other framework components) tend not to be so flakey, though.
IMHO, choice is stupid if you can't maintain it. One of the more convincing arguments that I've seen during the public formulation of GNOME 2.0's goals is the idea that umpteen million configuration combinations are a bad idea if only a small subset are frequently used. The ones that get used are the ones that get tested. Weird combinations get bugs that nobody knows about in advance since you can't test them. Weird configuration items turn into code bloat for too many special cases.
Now, the GNOME developers are human too. It seems to me that they had to learn this through hard experience, and make a priority call on what's important to them. Software requirements analysis is the process here - design the software to solve specific requirements, and cut out the things that waste too much effort.
So yeah - I think the GNOME guys are getting it right. So what if they've changed their tune - is it better to continue perpetuating a mistake?
But in this case, which of their customers are likely to bite? It's like their marketing team went off on a mission to solve a problem that doesn't exist - who exactly in the set of customers developing with Java is going to be deluded by the version number jump?
Here's a problem with peer-to-peer from the bottom up, at least in wireless. Which "joe user" with a cell phone wants to use up his meager battery life to help another peer transmit along?
Most cell phones are off 99% of the time, and only turn on a few tens of milliseconds every second or so to see if a call is coming in. If your handset is on to help someone else establish a connection, your battery drains as well as theirs. Any kind of ad-hoc network would seem to be completely inefficient in terms of power management.
So, what's the point?
This has been the case for cell phones for some time - if you purchase a phone with a contract, your initial investment for the handset itself is subsidized by the contract. It's the service that you pay for.
Simple hardware platforms don't lend themselves to incoming revenue. PC's have not been simple for a long time - RAM, disk, video cards, new LAN, USB stuff, etc., but there's got to be a business case for simpler PCs. Selling an expandable PCI chassis to my Dad and 99% of corporate and home users is a waste of resources. Instead, get the price down with a one-size-fits-all product, and then sell him something (service) that turns into a revenue stream...
Maybe Linux distro's for desktop use needs quality control? It's half way through 2004, and the current batch of distros (bsd included) are configuration messes. WTF happened?
It's really a function of the product's focus, and the resources the company can bring to bear on it. The majority of Red Hat's QA is focused on the product that they get paid for, RHEL. Fedora isn't bringing in any money, so it gets a lot less. If you keep in mind that Fedora Core is basically dogfood to provide interim releases of the stuff that goes into RHEL, and shake out early issues BEFORE paying QA to do work that the community (i.e., not necessarily the reviwer) is going to do for free.
I'm not up on VoIP protocols, but the codecs used for GSM and CDMA protocols use anywhere from 9.6kbps to 14.4kbps, IIRC. Is VoIP doing something else (say, to make up for the lack of a circuit?)
Wait till your voicemail starts filling up with spammer ads. Telemarketers apparently have no real incentive to leave a message, but I can guarantee that spammers with free access to your voice mail will ownz it the same way they do your INBOX.
From the FAQ:
The driver is based on a binary HAL...
So you'll likely have this problem with any newer distribution using kernel 2.6 until the driver gets brought up to 2.6 (assuming it hasn't already, I don't know for sure...)
FWIW, having worked at a small US company (just as cool a place as described by the parent poster to your message), and having watched it grow into a unit of a big US company, it's basically the same thing.
Big company == big money, at which point people get more uptight - no ifs, ands, or buts about it.
Yeah - he and Nick both missed the point there. GConf is just a pref management system used (in this case) to give people who really care access to an obscure preference.
Now, any particular user might disagree that making browse mode the default is obscure, but the Nautilus developers purposely decided that it was. They purposely didn't write a UI for it, but left the GConf key in for the same sorts of people who get bent out of shape if they can't pick obscure window manager settings like focus-follows-train or whatever.
You sure about that? On my Fedora 1 box, the default gnome menu runs printconf-gui, which is part of the redhat-config-printer package. (rpm -qf `which printconf-gui`)
Bonobo's used in eog (an image viewer) as well.
Pat Cadigan wrote some stories where a major plot premise is that anything that happens in a virtual online world has no legal bearing in the outside world. No censorship, no legally binding contracts, nada. Then she explores the idea. Check out 'Tea from an Empty Cup' and 'Dervish is Digital' - both are worth a read.
Yeah, and if that's not enough space, you can bzip2 the text and that'll probably do it, and get obfuscation out of it to boot (you know, like they did last time).
Except, of course, that while your dragging your folder a few inches to add it to the dock, and maybe wasting time mousing over a few in the dock to figure out which one is the one you want for any given app your using, the rest of us (using OS X) just open a file selector with apple-S and save the file with enter.
Nice troll, though!
I stand corrected. Thanks! Apologies for my non-flame to the orignal poster.
Perhaps. Although I have no problem telling the person on the other end of the hands-free kit that I'm driving, and I regularly ignore them as traffic dictates. Sure, it's more distracting, but by how much? I'd love to see a study that addresses that specific point. Not sure if it can be quantified, but it's the sort of thing that would get me to shut up, pun intended.
Please don't read this as a flame - but I'm going to be blunt. I don't have much sympathy for you using a laptop to get at GPS information. Unless you've got a great solid mount holding the laptop in a position where you can quickly move your eyes between it and the road, and a touch screen interface or some easy to hit buttons, it's unsafe to drive and use it at the same time, period.
The law doesn't seem to be overly broad in this case, for what it's worth, the law does permit the use of "installed" navigational devices, which presumably don't have the above mentioned problems. So your investment in unsafe equipment is wasted, but at least you're safer.
That said, I agreed with the rest of your post. The U.S. bashing was uncalled for.
It doesn't matter how quickly you can context switch if your eyes aren't on the road when something happens in front of you.
As long as a driver is using a handsfree kit and speech recognition or steering-wheel mounted controls, a cell phone's fine, but only under those conditions. If you can reduce the use of the cell phone to an activity like talking to someone in the passenger seat or back seat, with no other distractions, your in good shape. But as soon as hands start coming off the wheel, or eyes migrate to the LCD screen on the handset instead of the road, you (and everyone aroung you) has got a problem.
Probably because all of the fast-twitch first posters are still too hyped up on caffeine to actually have a 'quitting' story.
So, leaving aside issues of whether or not this is a good idea, are states' rights being encroached upon with this idea? States currently license engineers as they feel its necessary - why would software require federal licensing? Engineering is engineering, whether your twiddling bytes or blocks.
Presumably, open firmware doesn't have IP impediments (I dunno myself). ROM size could be at issue: This page indicates that you can't get an openfirwmare image in less than 128Kbytes, and practically, 256Kbytes is probably needed. Doran stated that their interpreter was 18Kbytes uncompressed, which is a pretty measley fraction of 128Kbytes. Anyone have any idea of how big a fraction of the 128Kbytes the forth interpreter is for Open Firmware?
Granted, I'm making a few assumptions here, like, there really is a good technical reason for this, and then trying to find it. Odds are, this really is just a play for control of the standard, but it would be nice to get a little more insight into the technical differences.