FWIW, Nautilus will fix the password entry, or at least work around it. Check out this post - it describes the keyring that should be able to fix it.
I think it's really just a workaround in the case of SMB browsing, although the keyring is a cool thing to add in general. Samba ought to be caching the password for the share in the connection, but the implementation only caches passwords for root users. I don't know if there's going to be a practical issue using the workaround, or if performance will improve significantly if samba gets a boost there. Time will tell (I really need some free time to hack - arguably I should quit reading/....)
It would have been nice to see Linus come back to it at some point, but it seems like he didn't (thread kind've peters off here, after Mark Doran posted on the goals behind EFI.
Nobody responded directly to that thread with any sort of rebuttal, but one interesting post by Eric W. Biederman did come out and say:
Things change and evolve. So far I know of two distinct versions of EFI. The EFI that has been so nicely described by Mark Doran. And the version I have actually used with is quite a different animal.
So the gist of it (my read, it's not written down anywhere) is that EFI is looking to be a major pain in the neck for open source developers, akin to ACPI, probably for the same reasons that Linus posted. Closed hardware/software sucks...
So, earlier someone posted a link to a summrary of a discussion on the Linux kernel list. An Intel guy pointed out some issues with the Openfirmware model that make some sense.
The way I read it is, hardware manufacturers want cheap products, and nobody wants to get locked in to supporting just one system architecture for an expansion card.
With something like openfirmware, apparently you have to have a ROM big enough to contain valid code that can run on both IA-32 and IA-64 and PPC, etc., or you end up with things like PC-only and Mac-only cards, which isn't cheap, either. So as nasty as ACPI has been from an implementation point of view, it seems like it does some stuff that open firmware can't do. Same can be said for EFI. Seems like a hell of a problem to me - damned if you do, damned if you don't.
Now, that said, no arguments about the other fringe benefits Intel gets from pushing the standard.
P.S. To my mind, Linus' post on the issue in the thread seems like something that your average software dude (self included) might come up with. Come up with simple hardware specs that don't need ROM code, and standardize on THAT. I'd kill for that kind of utopia in my line of work. I don't work in PCs, I work in embedded systems. All the hardware guys talk about gaining a competitive edge by locking people into their proprietary hardware via a software interface that they control. Same thing going on here - it's not the software dudes in the industry that need convincing - it's the hardware and business dudes who aren't looking to the future, but to the next product.
Well, neither did EFI till it was designed that way. What are the reasons why OpenFirmware++ couldn't be evolved to support it? (Hoping someone knows...)
It sounds like the EFI spec by far predates Microsoft's intent to license the FAT patents. I wonder if Intel knew that as the spec was being developed? Also, I wonder if the use of FAT for the filesystem is mandated by the spec, or if the EFI framework is extensible enough to allow the use of a different filesystem.
Hopefully FAT is just an implementation detail for the particular board being described, and not something we'll all be stuck with in the future. If FAT is part of the spec, companies like IBM had better start lobbying to get the spec changed before it gets standardized.
I work on this sort of thing for a different company, so I can say a little bit about what's likely going on under the hood. This sort of architecture sounds pretty standard for a modern smartphone, whether it's running Linux, WinCE, or Symbian. There are tons of these gadgets on the market already, with more on the way. They could be doing something atypical, but the specs make it sound fairly pedestrian (other than the use of Linux, still rare) - hence, I'd assume they went for the cheap (standard) path. (And yes, $600 sounds, if not cheap, at least normal for this sort of thing. Your typical wireless network operator selling a phone at a lower price is subsidizing the heck out of it, and you're paying it back with a multi-year service contract. High end phones can cost this much, easy).
The typical pattern is just like this one: one ARM to control the wireless modem/dsp functions, running an RTOS, and another ARM to run the applications on an OS like Linux. So the dual processor aspect is pretty normal - probably nothing special about this phone. If it follows the pattern, odds are that the processors aren't SMP - they run separate OSes to keep the real-time function separate from the smartphone function under Linux.
All these smartphone designs draw on the heritage of "dumb" phones made over the last decade or so. A "dumb" phone would only have one ARM processor, and run the cheesy sort of text oriented UI that's been typical till recently. This is pretty much just an evolution of an old, proven design. Slap another ARM on it, running at hundreds of MHz, fabricated with a top end process to keep the current draw down, and there you go. The parts that go into this thing are made in huge volume, keeping costs down. Basically, we're talking about processes as high tech as the ones in top-end desktops, but designed for reducing current draw, not increasing MHz.
As far as battery life goes, the name of the game is to turn the processors and the radio off as much as is possible. The modem processors and radio are rarely turned on - they wake up periodically, sometime for a duty cycle measured in tens of milliseconds every few seconds to check to see if anyone's calling. If not, everything gets shut down for another sleep period. They only stay on when in a call, and when that's the case, the current draw due to turning the transmitter on is going to dwarf the draw of the processors and receiver themselves.
You can say similar things about the second ARM that's running Linux. There's a whole lot of time between a user pressing keys or the touchscreen. Typical PDA functions shut the processor down in between bursts of CPU activity. Start playing a MPEG4 clip, and you'll see the battery drain that much faster, though. If the user isn't doing anything, the normal case, the thing goes to sleep practically forever.
So what are they going to use to heat the food back up? Even if they have something, is it worth the energy cost on a little self contained speck in the sky?
I bought quite a few MS products during the dark ages when I lived out-of-state. Originally, they weren't intended "for use in the state of California" but they ended up being used that way. The language of the settlement doesn't really state anything about intent. IANAL, and probably, YANAL, but does anyone have any idea if the products that I bought out of state qualify for the class now that I'm a California residents, and use them in-state? Vengeful minds want to know.
In any case, if you're like me and want to make sure that Microsoft pays 100% of the settlement rather than just 2/3, you might want to check the settlement notice. This part in particular may be of interest:
7. What if I'm not sure whether I'm included in the settlement?
If you are not sure whether you or your business is included in the Class, you may call the toll-free number 1-800-9605660 with questions. You may also write with questions to the lawyers appointed to represent the members of the class at Class Counsel, P.O. Box 2837, San Francisco, CA 94126-2837. DO NOT CALL THE COURT.
Authored by: fury on Monday, August 18 2003 @ 02:27 AM PDT
By the way (i forgot to mention this) the operators of xwin.org
(including Keith Packard) are not involved in Xouvert. xwin.org
!= Xouvert
On the other hand, the xouvert home page links directly to xwin.org in the page header. Hard to figure...
If it came to it, I imagine there'd be some negotiations for serious price slashing for volume discounts. $32 would kill profit margins something fierce.
This sounds wild. The broad definition in the article seems like it could apply to pretty much any wireless technology these days, including cell phones and wi-fi systems. Why did Blackberry get singled out? Are most companies already licensing this patent or something like that?
I use that, but it's awkward in that it doesn't stay in sync with the mailer. If I read the new messages in the mailer, the panel monitor doesn't get updated until it next polls that mailbox, which is something that I don't want it to do at too high a rate with my IMAP mail server.
Since I use evolution as my mailer these days, it seems pretty reasonable to put something in the panel notification area for this purpose. I'm not sure if there's a sane way to add a gnome dependency like that to mozilla or not, but it sure would be nice...
Big companies fund the work of university researchers all of the time, but that's a big leap between hacking on a palmtop prototype to actually getting the fruits of research into an actual phone. This sounds a lot more like vaporware than anything legitimate.
Yeah - you're absolutely right. I write firmware for usb devices, so reading this article, I came at it from the wrong direction entirely. This does seem pretty bogus!
The USB standards documentation has made this clear for a long time - years. USB 2 does add some new requirements to the spec for transfers at full and low speeds. So, to ship a USB 2 product, your hardware has to support some slightly different features, even if it can't do high speed transfers.
The same can be said about USB 1.1, which defines a low speed mode with a max speed of 1.5 Mbps. Your mice, keyboards, and other devices quite possibily use this mode, as it's cheaper to build. Just because you've heard that USB 1.1 has a max speed of 12Mbps, don't assume that all USB 1.1 devices are built to use that speed!
So, the rule of thumb is, don't equate USB 2 with high speed transfers. No big deal, if you ask me. USB 2 is the name of a technical standard, not a data rate!
Re:Asian manufacturers?
on
42-Volt Autos
·
· Score: 1
That's good to hear. Nothing's worse than an nonstandard standard!
The article made a point to state that the new standard is a result of an agreement between European and U.S. automakers? Does anyone have any idea how this plays out with Asian automakers?
You know, the reports of new crime and moral decay in the article sound fairly tame for most places that I can think of. Consider how many people find themselves wasting days per week watching televison.
Who's to say that we're really any more immune to this sort of influence, and that we haven't just written off the losses?
Seems like a lot of trouble to go to, huddling over a wireless doodad, trying to remotely connect to your desktop, when you can plan a script in advance at your desktop, with a real keyboard and display, and save the script for reuse later.
That said, please take the wireless approach - I work for a company that makes wireless doodads:)
Do you really want your condo homeowners' association to be legally liable for the conduct of each of your subscribers? With all of the legal action we've heard about targetted at ISPs of late, I'd think this is an invitation to bankrupt your HOA. Personally, I wouldn't touch this proposal with a ten-foot pole...
Is Infogrames producing any hardware? If, as the poster says, half of Atari went to Infogrames, you'd think that anyone associated with the actual hardware design has long since moved on, and to me that's the sad part of the whole thing.
Slashdot Mirror
FWIW, Nautilus will fix the password entry, or at least work around it. Check out this post - it describes the keyring that should be able to fix it.
/. ...)
I think it's really just a workaround in the case of SMB browsing, although the keyring is a cool thing to add in general. Samba ought to be caching the password for the share in the connection, but the implementation only caches passwords for root users. I don't know if there's going to be a practical issue using the workaround, or if performance will improve significantly if samba gets a boost there. Time will tell (I really need some free time to hack - arguably I should quit reading
So, earlier someone posted a link to a summrary of a discussion on the Linux kernel list. An Intel guy pointed out some issues with the Openfirmware model that make some sense.
The way I read it is, hardware manufacturers want cheap products, and nobody wants to get locked in to supporting just one system architecture for an expansion card.
With something like openfirmware, apparently you have to have a ROM big enough to contain valid code that can run on both IA-32 and IA-64 and PPC, etc., or you end up with things like PC-only and Mac-only cards, which isn't cheap, either. So as nasty as ACPI has been from an implementation point of view, it seems like it does some stuff that open firmware can't do. Same can be said for EFI. Seems like a hell of a problem to me - damned if you do, damned if you don't.
Now, that said, no arguments about the other fringe benefits Intel gets from pushing the standard.
P.S. To my mind, Linus' post on the issue in the thread seems like something that your average software dude (self included) might come up with. Come up with simple hardware specs that don't need ROM code, and standardize on THAT. I'd kill for that kind of utopia in my line of work. I don't work in PCs, I work in embedded systems. All the hardware guys talk about gaining a competitive edge by locking people into their proprietary hardware via a software interface that they control. Same thing going on here - it's not the software dudes in the industry that need convincing - it's the hardware and business dudes who aren't looking to the future, but to the next product.
Well, neither did EFI till it was designed that way. What are the reasons why OpenFirmware++ couldn't be evolved to support it? (Hoping someone knows...)
It sounds like the EFI spec by far predates Microsoft's intent to license the FAT patents. I wonder if Intel knew that as the spec was being developed? Also, I wonder if the use of FAT for the filesystem is mandated by the spec, or if the EFI framework is extensible enough to allow the use of a different filesystem.
Hopefully FAT is just an implementation detail for the particular board being described, and not something we'll all be stuck with in the future. If FAT is part of the spec, companies like IBM had better start lobbying to get the spec changed before it gets standardized.
None whatsoever!
I work on this sort of thing for a different company, so I can say a little bit about what's likely going on under the hood. This sort of architecture sounds pretty standard for a modern smartphone, whether it's running Linux, WinCE, or Symbian. There are tons of these gadgets on the market already, with more on the way. They could be doing something atypical, but the specs make it sound fairly pedestrian (other than the use of Linux, still rare) - hence, I'd assume they went for the cheap (standard) path. (And yes, $600 sounds, if not cheap, at least normal for this sort of thing. Your typical wireless network operator selling a phone at a lower price is subsidizing the heck out of it, and you're paying it back with a multi-year service contract. High end phones can cost this much, easy).
The typical pattern is just like this one: one ARM to control the wireless modem/dsp functions, running an RTOS, and another ARM to run the applications on an OS like Linux. So the dual processor aspect is pretty normal - probably nothing special about this phone. If it follows the pattern, odds are that the processors aren't SMP - they run separate OSes to keep the real-time function separate from the smartphone function under Linux.
All these smartphone designs draw on the heritage of "dumb" phones made over the last decade or so. A "dumb" phone would only have one ARM processor, and run the cheesy sort of text oriented UI that's been typical till recently. This is pretty much just an evolution of an old, proven design. Slap another ARM on it, running at hundreds of MHz, fabricated with a top end process to keep the current draw down, and there you go. The parts that go into this thing are made in huge volume, keeping costs down. Basically, we're talking about processes as high tech as the ones in top-end desktops, but designed for reducing current draw, not increasing MHz.
As far as battery life goes, the name of the game is to turn the processors and the radio off as much as is possible. The modem processors and radio are rarely turned on - they wake up periodically, sometime for a duty cycle measured in tens of milliseconds every few seconds to check to see if anyone's calling. If not, everything gets shut down for another sleep period. They only stay on when in a call, and when that's the case, the current draw due to turning the transmitter on is going to dwarf the draw of the processors and receiver themselves.
You can say similar things about the second ARM that's running Linux. There's a whole lot of time between a user pressing keys or the touchscreen. Typical PDA functions shut the processor down in between bursts of CPU activity. Start playing a MPEG4 clip, and you'll see the battery drain that much faster, though. If the user isn't doing anything, the normal case, the thing goes to sleep practically forever.
So what are they going to use to heat the food back up? Even if they have something, is it worth the energy cost on a little self contained speck in the sky?
Hey, I realize the FCC is all-powerful and whatnot, but they certainly didn't approve a "bill". Leave that to our Congress, eh?
I bought quite a few MS products during the dark ages when I lived out-of-state. Originally, they weren't intended "for use in the state of California" but they ended up being used that way. The language of the settlement doesn't really state anything about intent. IANAL, and probably, YANAL, but does anyone have any idea if the products that I bought out of state qualify for the class now that I'm a California residents, and use them in-state? Vengeful minds want to know.
In any case, if you're like me and want to make sure that Microsoft pays 100% of the settlement rather than just 2/3, you might want to check the settlement notice. This part in particular may be of interest:
7. What if I'm not sure whether I'm included in the settlement?
If you are not sure whether you or your business is included in the Class, you may call the toll-free number 1-800-9605660 with questions. You may also write with questions to the lawyers appointed to represent the members of the class at Class Counsel, P.O. Box 2837, San Francisco, CA 94126-2837. DO NOT CALL THE COURT.
Check out this comment from the xwin.org post:
Authored by: fury on Monday, August 18 2003 @ 02:27 AM PDT
By the way (i forgot to mention this) the operators of xwin.org (including Keith Packard) are not involved in Xouvert. xwin.org != Xouvert
On the other hand, the xouvert home page links directly to xwin.org in the page header. Hard to figure...
If it came to it, I imagine there'd be some negotiations for serious price slashing for volume discounts. $32 would kill profit margins something fierce.
This sounds wild. The broad definition in the article seems like it could apply to pretty much any wireless technology these days, including cell phones and wi-fi systems. Why did Blackberry get singled out? Are most companies already licensing this patent or something like that?
I use that, but it's awkward in that it doesn't stay in sync with the mailer. If I read the new messages in the mailer, the panel monitor doesn't get updated until it next polls that mailbox, which is something that I don't want it to do at too high a rate with my IMAP mail server.
Since I use evolution as my mailer these days, it seems pretty reasonable to put something in the panel notification area for this purpose. I'm not sure if there's a sane way to add a gnome dependency like that to mozilla or not, but it sure would be nice...
It's there:
b eh avior_system_calls
http://www.acm.uiuc.edu/sigmil/RevEng/x288.htm#
Big companies fund the work of university researchers all of the time, but that's a big leap between hacking on a palmtop prototype to actually getting the fruits of research into an actual phone.
This sounds a lot more like vaporware than anything legitimate.
Yeah - you're absolutely right. I write firmware for usb devices, so reading this article, I came at it from the wrong direction entirely. This does seem pretty bogus!
The USB standards documentation has made this clear for a long time - years. USB 2 does add some new requirements to the spec for transfers at full and low speeds. So, to ship a USB 2 product, your hardware has to support some slightly different features, even if it can't do high speed transfers.
The same can be said about USB 1.1, which defines a low speed mode with a max speed of 1.5 Mbps. Your mice, keyboards, and other devices quite possibily use this mode, as it's cheaper to build. Just because you've heard that USB 1.1 has a max speed of 12Mbps, don't assume that all USB 1.1 devices are built to use that speed!
So, the rule of thumb is, don't equate USB 2 with high speed transfers. No big deal, if you ask me. USB 2 is the name of a technical standard, not a data rate!
That's good to hear. Nothing's worse than an nonstandard standard!
The article made a point to state that the new standard is a result of an agreement between European and U.S. automakers? Does anyone have any idea how this plays out with Asian automakers?
You know, the reports of new crime and moral decay in the article sound fairly tame for most places that I can think of. Consider how many people find themselves wasting days per week watching televison.
Who's to say that we're really any more immune to this sort of influence, and that we haven't just written off the losses?
Seems like a lot of trouble to go to, huddling over a wireless doodad, trying to remotely connect to your desktop, when you can plan a script in advance at your desktop, with a real keyboard and display, and save the script for reuse later.
:)
That said, please take the wireless approach - I work for a company that makes wireless doodads
eom
Do you really want your condo homeowners' association to be legally liable for the conduct of each of your subscribers? With all of the legal action we've heard about targetted at ISPs of late, I'd think this is an invitation to bankrupt your HOA. Personally, I wouldn't touch this proposal with a ten-foot pole...
Is Infogrames producing any hardware? If, as the poster says, half of Atari went to Infogrames, you'd think that anyone associated with the actual hardware design has long since moved on, and to me that's the sad part of the whole thing.