Microsoft does it's best (or worst) to provide something. But, heck, it's FREE. IE costs us nothing.
Wait, I thought that Internet Explorer was an integral part of the Windows operating system, not a separate product! I paid good money for that operating system!
(Obligatory scare quotes: I paid "good money" for that "operating system".)
The AgendaVR, Yopy, and Sharp PDAs are "Linux PDAs". This is a proprietary PDA that happens to use a Linux kernel.
So what's a non-proprietary PDA?
This is not a "Linux" PDA in any useful sense: it doesn't run Linux utilities, it thumbs its nose at the open source process, and even its kernel software development appears to take part outside the Linux community.
And the opposite is true of the VR3. It runs desktop-style Linux utilities, complete and Open Source is available for everything on the box, and the kernel is a relatively standard linuxvr/linuxmips kernel.
I think the only way you could claim the VR3 is a "proprietary PDA" is that the schematics and license for the hardware are not freely available. But by that standard, the hardware you're using right now is proprietary. (OK, there are probably a few slashdot readers on homebrew/reference/open hardware right now; feel free to hit reply...)
The VR3 isn't perfect. It has many things wrong with it. But it's the flag carrier for development of PDA systems Linux-style. Well, handhelds.org wins for repurposing the iPaq hardware, but Compaq isn't corporately dedicated to supporting Linux on that PDA.
(Insert rant about what "Linux" really means here. Imagine I claimed that glibc+kernel was the most useful definition right now.)
Unless you're want higher performance video, I think you should get the base, $1000 Blade 100 and add memory yourself. It takes standard PC133 memory. (I've heard conflicting reports on whether it supports random non-Sun IDE drives.)
OTOH, if you just want 32-bit Unix performance, you're going to be rather envious of your cubemate who bought a Dell OptiPlex GX 150 P3/1.13 512M 80G for the same price, and plopped Debian on it....
Signed,
An Ultra 10 owner who switched from Solaris 8 to Debian/SPARC:-/
(OK, now that I've established my credentials...:-P )
You folks should react to new products differently. New Linux products are an opportunity, not a threat.
Let's do iPaq vs Zaurus first.
The Zaurus hardware architecture is substantially similar to the iPaq. Even if the kernel sources are maintained separately, you should be able to run the same distributions on the the Sharp as on the Compaq (once we do any needed X server changes). So if you're really dedicated to the handhelds.org community, this gives you the opportunity to choose between two hardware vendors and devices to run Familiar on. Competition is good, right?
Now, what about handhelds.org/familiar vs Zaurus Linux? Well, there's still a lot of lingering questions about the efficacy of the X11 architecture for handhelds. Sharp's commitment to QTE means they've spent a lot of resources on building a nice environment on top of it. So for you, the opportunity is to let Sharp spend a lot of money finding out how well the QTE architecture really works. And if they're right, because this is Open Source you have the opportunity to take the basis of their code and use it yourself. No risk.
What about the Java angle? Jeode isn't Open Source. But PocketLinux is. (And appears to have some very active development lately.) If Jeode is doing some things right, PocketLinux gets to pick up the best of their ideas for free. The opportunity is to explore the viability of Java and alternatives for Java application architectures for handhelds, and again, at no cost to you.
Stop thinking of yourself as a member of the handhelds.org community, or the PocketLinux community, or the Agenda VR3 community.
Start thinking of yourself as a member of the Open Source community---with particular interests: handhelds, information management tools, multimedia, task mobility....
We don't know what the right answers are to all of the hard questions that face us; we don't even know all the questions. But we can share our results, change direction, and work on parts of the problems as we ourselves see fit. When companies produce Linux products, they're another research staff and contributor to this, not a dictator. That's the value proposition of Open Source in emerging technologies.
NET and Java are not even in the same class. One is a language. The other is a marketing buzzword that covers a variety of technologies. Be more precise. What part of.NET are you talking about?
The JavaTM platform is based on the power of networks and the idea that the same software should run on many different kinds of computers, consumer gadgets, and other devices. Since its initial commercial release in 1995, Java technology has grown in popularity and usage because of its true portability. The Java platform allows you to run the same Java application on lots of different kinds of computers.
[...]The idea is simple: Java technology-based software can work just about everywhere. Java technology components don't care what kind of computer, phone, TV, or operating system they run on. They just work, on any kind of compatible device that supports the Java platform.
Notice how they don't say "Java is a language..."?
In the Java 1.0 days there were essentially three things referred to as Java: the JVM, the language, and the standard library. Oh, and maybe something about delivery of applets through sandboxed bytecode. Four things Sun wanted you to think of for the term "Java". Now there are a zillion. Soon, there will be a zillion and fifty.
OK, OK, those aren't at the same architectural level as the big three components. But "Java" has become increasingly vague, and don't think Sun isn't encouraging this. They want non-directed feelings of goodness associated with whatever's in their (proprietary) platform this week.
If what people wanted from Java was just a language, in the traditional view of what a language is, gcj would have taken over the world by now.
The PalmOS is built from the ground up as a handheld, all-in-RAM, XIP OS. Linux is originally a server OS.
No, Linux is originally Linus's terminal emulator project. Then it was a replacement for Minix, a free Unix operating system that people could run on widely available, inexpensive desktop hardware. And in that role, it was primarily used first as a desktop box; only later (think post 1.0) were people starting to deploy it widely as a server platform.
Also, some Linux platforms run XIP. It's fairly easy to make the kernel itself run in place on linear ROM; just a few linker script tweaks. The Linux VR kernel also supports XIP for chosen exectuables and shared libraries, thanks to Rob Leslie's work on XIP for cramfs. On a file by file basis, you get a choice between uncompressed execute-from-ROM via MMU, or cramfs's block-by-block compression for executables you don't expect to be paged in as much.
Yes, Unix systems tend to think of the world in terms of files. But for specific, chosen access styles, under the hood the files can be accessed just as efficiently as a fileless PalmDB scheme. Unix gives you a choice of how to do it, and you're not stuck with it; you can still read() and write() to files you're usually treating as memory-mapped databases. (With whatever synchronization you deem necessary; PalmOS doesn't have concurrent access synchronization problems because it, like DOS, only supports one program running at a time.)
Actually, WinCE has support for XIP as well, but I don't know enough about it to post anything authoritative.
Sure, a company could take the Linux kernel and tools and write a Palm-esque interface for it, and rewrite the guts enough to be naturally resource-based XIP.
And every company is going to have their own "redux Tux", which means you won't be able to generate a single executable file that you can throw on any device, the way you can with a Palm.
In other words, desktop Linux people should give up because a) you can't just throw a Windows or Mac executable on any machine and expect it to work. In fact, Apple should give up as well.
Nah. Diversity is a good thing. It's what got Linux here. It's what got *BSD here. We wouldn't have Gnome or KDE if they hadn't decided to dump Motif and Athena.
Re:"This is perfect for traveling"?
on
iPAQ 3800 In Photos
·
· Score: 3, Informative
Yes. Bluetooth is supposed to be the answer to this---although people have vast ambitions for using Bluetooth as a network protocol etc, it was originally designed as the answer to the connector conspiracy. It hooks together your hardware. Power is still a problem, so for various reasons I think we're going to be stuck with device-specific chargers for some time.
Think of Bluetooth as USB without wires. Ignore the hypemeisters who want to use it to deliver locale-enhanced portal services, or whatever it is they're trying to sell now.
If Bluetooth succeeds, it will be as a cable replacement first.
SD slots are a superset of MMC, the MultiMediaCard. Any MMC media should work in an SD slot. Uh, I forget whether I'm NDA'd on the details of SD (damn click-through licenses) but I think you should be able use SD cards that don't have "secure" content on free operating systems.
BTW, the MMC interface is quite simple; it's the kind of interface you could build in a second EE course on design with microcontrollers. Much simpler design than CF.
Don't get excited about the Ultra 5/10 and the Blade 100. They have the heart and soul of a PC---IDE disk, ATI video, PC133 memory, (mostly) standard case and chassis. Unfortunately, they don't have the performance of a PC.
I ran around running my Linux cross-compile benchmark on a bunch of Sparcs. The 1G RAM, 440MHz Ultra 10 checked in with performance that was strictly worse than the 320M 450MHz iMac DV+. The 500MHz Blade 100 was around 10% better. Now, these figures are probably a tad low; I realized after the fact I was using an SMP-enabled kernel, and that adds overhead even on a single-processor machine. So credit them with another 10% until I get publish-worthy numbers. The Sparcs are still crushed by the 733MHz P3 el-cheapo Dell Optiplex, and the (badly-configured) Athlon 1200 has nothing to fear.
The Blade 1000 is a different beast. It's a real workstation, with 8M caches---can't get that in the beige box x86 world, and there are a lot of workloads that are just screaming for it. I don't have numbers yet, but I expect they'll be much more competitive. Of course, for $15-20k for a dual processor box, they'd better be.
So why buy a Blade 100?
Binary compatibility with bigger machines. If you think your app is going to have to scale up to mainframe size, you won't have to recompile your system to take it there.
Commercial software compatibility. No Purify for Linux, for instance. Or maybe you already bought big-ticket software like RealServer, or a GIS.
Compatibility with collaborators. In some communities (especially research), Solaris on SPARC is a very common environment.
64 bits. The Blade 100 is the cheapest 64-bit PC in the world. Some people need to develop for a 64-bit world. (It's not the cheapest 64-bit Linux hardware; although current kernels don't support it, the Agenda VR3 hardware is a full 64-bit MIPS implementation.)
By the way, newer kernels improved the Mac performance substantially, and SMP provided around a 60% speedup on the tests on the dual 533MHz PPC. I think I know where to borrow a dual 800MHz PowerMac, which should finally beat the crap out of the Athlon 1200. Of course, now I'm curious about dual Athlon performance, but I dunno if I really need a new machine just to run some benchmarks...
(If there are moderators still reading this, please mod the parent up.)
I agree that IBM in the server space is the classic example of a systems company that works. But IBM's services are far more broad than what Apple provides; Apple isn't in the business of producing end-to-end products and services. And even IBM lately is waving the unbundling banner with their Linux push. Vertical integration can provide great benefit to customers, but often it's used to extract high profit margins from customers once committed---and you can ask IBM's customers about that.
I don't think my analysis is patently false (obviously). The cloners did use board designs incorporating R&D from Apple, and that was negotiated. Apple could have named an appropriate per unit price to compensate. But then there's PReP. With PReP and CHRP, IBM and Motorola provided significant amounts of engineering and the reference designs, if I recall correctly. Motorola sure wanted to get more PPCs out the door, so they were highly motivated to produce designs for motherboard manufacturers.
Apple's goal with the cloners was also to look like they were open. There was significant corporate misgivings about sole-source hardware, and with Microsoft pretty much destroying every other vertically integrated personal computer hardware manufacturer, it left Apple vulnerable to these kinds of worries.
In a perfect world, the cloners would have been encouraged to innovate on the hardware side as well, of course. But I agree with your position that the cloners got their hardware designs far too cheaply, and had no reason to push.
Power Computing put themselves out of business by their actions, but that happened because of poor licensing contracts, and a complete misunderstanding of their relationship to Apple. But Apple lost a real opportunity to be the benchmark manufacturer and software licensor for an industry, rather than a lone wolf.
If Apple weren't a software company, they could just jettison all the expensive MacOS development work and produce translucent, elegant, highly certified and tested x86 machines, and save a bundle.
If Apple were a hardware company, they wouldn't have lost so badly when the clone makers gave Apple's customers what the customers wanted---inexpensive, powerful machines that ran MacOS, without logos, frogdesign, or ad campaigns. Instead, Apple was forced to reconsider what made them competitive, and yanked all the software licenses.
Back in the days of PReP (a joint IBM/Motorola/Apple standard for PowerPC motherboards), Apple stonewalled on support, claiming there were problems getting MacOS to run on PReP hardware---they couldn't get it to work without having Mac ROMs, and there was some problem with *that*, and etc etc etc. A small Swiss software company (I believe called Qix) demonstrated MacOS running on PReP hardware, and IIRC Apple threatened them into little pieces. Later, Apple sorta endorsed CHRP, a successor to PReP, this time with a spot for those all-important Mac ROMs to live. But Apple never shipped MacOS for CHRP; this was the era when Apple was retaking control over hardware that could run MacOS. Of course, all that talk about engineering requirements for Mac ROMs in hardware turned out to be bullshit; the iMac next to me has OpenBoot ROMs, and loads the Mac ROMs from the hard drive.
Apple's work on PReP and then CHRP, and their commitments to supporting MacOS on those platforms led to great hopes for a commodity market in PowerPC motherboards, especially among Linux weenies like me who wanted widely available, appropriately priced non-x86 desktop machines available. Apple's broken promises are a part of why more of you aren't running Linux on non-x86 machines. But hey, at least Apple got to keep their software locked up.
Locked up? Well, maybe that's the wrong concept. Let's think of Apple-branded hardware as a Really Big Dongle, a copy-protection mechanism for MacOS. (The CPU incompatibility also keeps them from looking like they're competing with Microsoft, which makes Microsoft happy.)
Here's a fun experiment. Sit down with the parts list for a modern Mac and compare it to a well-built, well-designed Windows box from a first tier vendor, like Sony. The two machines may even have a lot of identical parts, now that Macs have PC133 memory, PCI, AGP, IDE hard drives, etc. Once you get done, add ~15-20% to the price of the PC to compensate for the generally better quality and design of Macs (if you believe that.)
If you do this across Apple's product line, you'll notice price differences anywhere between $75-100 for iMac-like machines to several hundred dollars on the high end boxes. Part of that margin is what pays for R&D, and in particular, OS development. So in some sense, Apple prices their OS by the capabilities of the hardware it runs on. Microsoft can only dream of this kind of profit maximization through differentiated pricing. Oh, and the license isn't transferable; you end up buying a new MacOS license fee when you buy a new Mac. That's how Windows OEM licenses are supposed to work; there's still a fair amount of piracy of Windows onto beige boxes, but Apple avoids that too.
Anyway, a potentially important reason why Apple hardware retains value is that a significant portion of original hardware cost is actually paying for the MacOS Dongle. Even as the cost of the hardware depreciates, the price of the ability to run MacOS does not depreciate as sharply.
That's fine if you're the one who actually signed up. Me, nop@nop.com, and my friend ben@ben.com, get truly fascinating spam by way of people who are enticed to give some email address in return for something; somewhat believably, people will use fake email addresses under duress.
In addition to all the random female-depicting porn you're familiar with, I get aluminum market newsletters, British SMS-music-info-service announcements, and some very tasteful Swedish news mailings. Oh, and for a while nop@nop.com was listed as the contact address for a gay personals service ad in Portugal. The letters I got were very sweet, but my wife still thought it was funny...
My favorite is when people buy unlock codes for commercial software, giving my email address. I've got a whole folder full of registration codes that I didn't pay for and will never use....
Oh right, back to opt-in. So here's what's going on.
When spammers say "opt-in" they mean that at least somebody typed an email address into a web page somewhere.
When spammers say "double opt-in" they mean the horrible, onerous, business-destroying requirement to confirm that the person receiving mail at an email address wants to receive their mail. Anti-spammers prefer to call this "verified opt-in", and I like that term better, but it doesn't matter what you call it.
So when somebody types nop@nop.com into the signup for Goatmail (intentionally goating me or not), a verified opt-in system sends nop@nop.com a message saying "hi! hit reply to this message to confirm and enter the wonderful world of goats!" With non-opt-in systems, I'm in Goatland without any further delay. Sort of like when my "friends" sent all the "I'm interested!" postal reply cards to the Navy recruiters AND the dental post-doc programs with my address on them. Took years to get rid of them.
But I digress again. Here's the summary:
Unverified opt-in means someone wishes for an email address to receive spam.
Verified opt-in means the recipient of mail sent to an address wants spam.
Originally I read this as "are often willing to build their own car". And written that way, I was looking for the +1, Funny, because that kind of post is great satire on the typical slashdot user:
"oh sure, we're going to (embark on lengthy silly task) because that way it will be Free!! It will r0x0r!!"
"Well, how far have you gotten?"
"We have a sourceforge site and some PHP and somebody did a killer Flash intro..."
The Dragonball CPU used in here doesn't have an MMU, which means that you don't get all kinds of things like memory protection, demand paging, fixed address executables etc. Oh, no fork() either. No glibc, so porting gets harder too.
Don't get me wrong; ucLinux is still very cool, but it's not in the same league as the Agenda VR3, VTech Helio, or mono iPaq. Of course, they're all at least double the price....
Why I bother posting to articles that are past the attention horizon of moderators is beyond me, but I'm feeling grumpy today.
The is no clear separation between the environment and the program.
Traditional Smalltalk weakness, yes, but it does have some significant benefits, or else it would have been thrown out somewhere in the 29 year history of Smalltalk. It frustrates me and other people immensely, which is why there's active work on modularization and declarative program specification.
There is a confusion between a pointer and the object itself.
Confusion by whom? Certainly not the implementation; it works. Confusion in the language specification? No. Confusion relative to other systems? No, there are plenty of other systems in common use with the same semantics; Java, Python, Lisp, are the first to come to mind. Confusion on your part? I can't answer that.
There is no finalaization (destruction)
That's just not true. See Object>>finalize.
There is a single memory model for instances (heap) versus, for instance, C++es minimum of 4 (heap, stack, static, member-of-another-object)
There is a single programmer-visible allocation model. The implementation may choose heap or stack allocation. If by "static" you mean "gets placed in the initialized data or BSS sections", well, until somebody coughs up a decent image->ELF executable tool, this isn't an issue.:-( Member-of-object could also be an implementation choice, but I'm not aware of people pushing on it.
Why do you want multiple programmer-visible allocation models?
There is a single model of memory management (garbage collection over ALL objects - lose them and the memory eventually returns - sometimes after a sudden "freeze" of the program). It is automatic and can't be replaced with improved handling of special cases.
Most language systems have only a single model of memory management. For instance, C++ as commonly used has malloc-new/free-delete; anything beyond that is up to all of the libraries and user code to agree on. You can have endless fun with C++ class libraries fighting over which smart pointer scheme and container deallocation policy is going to win.
IMO one of the best multiple model systems I've used is in Modula-3, where normally all references are "traced"---automatically managed. But modules marked unsafe could manipulate untraced references and do all that pointer arithmetic that C jocks think they can't live without. Of course, there was a lot of peer pressure not to mark your modules unsafe unless there was a good reason, which made people carefully consider whether they really had to do risky things to get their part of the job done to the required performance standards.
Let's get to particulars. Squeak's collector is generational. Object memory is divided into "young" and "old" objects. Since the vast majority of objects are used once and forgotten, we don't need to scan "ALL" the objects to do most collections. Eventually, yes, we need to do a full collect, but this is fairly rare. You're right that this is problematic for realtime apps, and I don't know what people do about it. But given the frequency my Linux and W2k boxes decide to go thrash a little due to background tasks, I suspect it's acceptable for other apps.
Btw, the GC stats from the random image I pulled up claim 6507 minor GCs at average 9ms, and one full GC (which I explictly triggered) at 627.0ms.
I don't really feel like getting into the whole "GC is good/bad" flamewar; there are a lot of subtle issues on both sides, and I don't think I can argue either side with authority.
There is no strong typing.
Blah blah smalltalk/scheme/etc are strongly typed and latently typed blah blah.
You're right, in that there are not tools commonly in use to allow programmers to specify that arguments must conform to particular protocols. (You don't want to say "is an instance of class Collection" because subclassing is not subtyping; you want to say "must support the add: and remove: protocol"). That being said there are various type inference systems people are playing with.
The environment is hostile to multi-programmer cooperation.
Yes, and this is a serious weakness of most language environments in current use. A lot of energy and dollars have been spent on trying to provide collaboration tools for static languages like C, and even there the results haven't been satisfactory. Witness all of the CVS replacement projects and commercial source control tools.
Smalltalk's changeset tools are better than nothing, I guess. Other people in the thread have mentioned various multiprogrammer tools for Smalltalk, like ENVY; I haven't used any of them, but I think they're the rough equiv of CVS. That's not good enough.
Extreme Programming originated as a methodology for supporting multiprogrammer collaborative projects in Smalltalk, so it's not like the environment keeps you from doing this, especially if you have decent policies in place.
Once the Squeak people come up with a good module system, I suspect the collaboration issue will significantly improve.
As far as language-level support for multiple programmers goes, the best examples are mud implementation languages; I work on MOO, which might be a good place to mine for ideas.
The language design allows incomplete programs to appear to run, encouraging the release of incomplete and buggy programs.
True of many languages in common use, of course. C and C++ force you to have definitions for all symbols referenced at link time, so what people end up doing is writing stub functions defined as die("i'm not written yet"), which gives you exactly the same failure mode as an incomplete Smalltalk program.
The Squeak environment will complain loudly at you if you compile code that references method names that aren't defined anywhere.
Those two paragraphs are just a flail at what I'm guessing you mean there. With such a vague condemnation of Smalltalk systems and the people who use them, I don't know how to respond to particulars. If you meant something else, please follow up.
Methods (member functions) of subclasses (derived classes) are executed during construction of the superclasses (base class), invalidating the debugging of the superclass (base class) constructor.
Yes, and I think I ran into this one time. Luckily, new instance variables are initialized to nil, so you won't get the disasterous results of following uninitialized C-style pointers.
IMO there aren't any entirely satisfactory constructor systems in any language I know; I've been bitten by them all. C++ goes to great lengths to try to address these issues, and as a result ends up with a great deal of conceptual complexity, and that cure sometimes feels worse than the disease.
I could go on.
If you did, we could discuss those issues rather than handwaving them. OK, OK, yes, this is slashdot and not the right medium for long conversations, and I'm getting tired of typing too.
Smalltalk is useful for throwing together a program to run once to get an answer to a question or sometimes to test an idea. It is totally unsuitable for the construction of mission-critical or commercial-grade applications.
Smalltalk is a pretty good prototyping language. Whether it's suitable for a given set of people to use to build a particular mission-critical or commercial-grade application is highly dependent on local circumstances, as is the choice of any other language. Because of its strengths and weaknesses, Smalltalk has been used successfully to produce many bespoke mission-critical applications; for lots of reasons, especially runtime licensing and business models, it has not been successful as a shrinkwrap dev environment. Its poor fit into Unix's process model hasn't helped either. (Lisp and Java have similar problems btw.)
Since the problem here is to create an environment for writing code you want to DISTRIBUTE to a large number of people who will use them without being inside their development, it's an amazingly wrong language choice.
I think that's too strong. At this point, systems that in the past were condemned for bulk/model issues, such as Common Lisp, are dwarfed by Java. I mean, if you thought CL had a bunch of thick manuals, you'll be appalled at how heavy the books describing the contents of the Java 2 "Standard Edition" are.
I'm on vacation from Squeak. I got burned out banging my head against some of the modularity issues, and frustrated by how hard it was to build "conventional" user interfaces in it. I can zap out a simple button/entry/list/dialog box UI in Lua FLTK much faster than in either of Squeak's two UI systems. I'll probably return though. There's something really attractive about Squeak's environment, goals, and its incredible development community.
KSR had a line in a book somewhere that went something like this:
"Libertarians want just enough government to keep their slaves from revolting."
Over the top, sure, but it's got a grain of truth in it. Ever since I read that, this former die-hard libertarian has been much more skeptical of the glorious and righteous claims from libertarians. It's important to look behind the big important words and figure out what's actually being argued.
In this case, arguments for "proprietary" software licenses are arguments for the use of government force on the behalf of copyright holders. I mean, all this talk about "intellectual property" is eventually backed up by state power (with guns as the final resort), right?
That's not to say that I think enforcement of copyright and contract law is necessarily or entirely a bad thing. In fact, we get a lot of good out of copyright. But I think we need to look at actual causes, effects, benefits, and costs when discussing these issues rather than taunting each other with "look, I have more liberty than you!"
And this use of the law advances the public good...how?
My meter for "be careful, somebody's trying to pull a fast one" now trips when the discussion's terminology gets "Intellectual Property" added to it. There is no such thing in the law.
There are legal mechanisms for patents, trade secrets, copyrights, trade marks, service marks (and a few others), but none of these legal mechanisms are as strong or complete as those laws related to real property. And that's as intended; real property and intellectual creations have very different characteristics.
People who are pushing the term "intellectual property" into arguments often are indicating their desire to make the legal controls[1] over information creations to be as strong or stronger than those over tangible property. So that not only means eliminating fair use and expiry, but also the creation of new categories of government control mechanisms for those things that inconveniently don't fit into the existing legal structures.
[1](Note "controls"; "protections" is another attempt to shift the terms of the debate.)
Smalltalk: You send the message shoot to gun, with selectors bullet
and foot. A window pops up saying Gunpowder doesNotUnderstand: spark.
After several hours fruitlessly spent browsing the methods in Trigger,
FiringPin and IdealGas, you create ShotFoot, a subclass of Foot with
a new instance variable bullet hole.
Me, I'm still trying to figure out a good one for Lua (which is too hip a language to have slashdot stories about it yet.)
View the contents TCP packets? I'd probably use sniffit which will reconstruct the content of the TCP stream for you. Of course, if you're actually trying to debug TCP itself ("hey, look at this Solaris box spamming retransmits") you back off to something like tcpdump.
The great thing about sniffit is that other people will, uh, install it for you on Internet-exposed machines...
Oh, cmon. Quoting unstripped library sizes is flamebait. From Debian 2.2:
nop@bandwagon:~$ ls -l/lib/libc-2.1.3.so
-rwxr-xr-x 
1 
rootroot
 
887712Mar2517:35 /lib/libc-2.1.3.so
nop@bandwagon:~$size /lib/libc-2.1.3.so
text data bss dec hex filename
869332 13232 15132 897696 db2a0/lib/libc-2.1.3.so
That's not to say that an 800k libc on x86 isn't big. It gets even bigger on more RISCy platforms like MIPS. The Agenda people are sticking with a patched glibc-1.0.3 until they can decide how to rationally compile out features.
In my opinion (which is not so humble after a lot of embedded Linux hacking), Linux is defined as not just a kernel, but also by libc. I can live with all kinds of wacky new kernel features as long as the C library uses and hides them from me. But changes, even bug fixes, to libc can break code in all kinds of unexpected places. Remember when Netscape needed a very specific libc version in order to cope with netscape's, uh, issues?
The people who work on glibc deserve a lot more respect and visibility.
Slashdot Mirror
Wait, I thought that Internet Explorer was an integral part of the Windows operating system, not a separate product! I paid good money for that operating system!
(Obligatory scare quotes: I paid "good money" for that "operating system".)
Hey moderators, mod parent up. The AC said what I was gonna say.
The AgendaVR, Yopy, and Sharp PDAs are "Linux PDAs". This is a proprietary PDA that happens to use a Linux kernel.
So what's a non-proprietary PDA?
This is not a "Linux" PDA in any useful sense: it doesn't run Linux utilities, it thumbs its nose at the open source process, and even its kernel software development appears to take part outside the Linux community.
And the opposite is true of the VR3. It runs desktop-style Linux utilities, complete and Open Source is available for everything on the box, and the kernel is a relatively standard linuxvr/linuxmips kernel.
I think the only way you could claim the VR3 is a "proprietary PDA" is that the schematics and license for the hardware are not freely available. But by that standard, the hardware you're using right now is proprietary. (OK, there are probably a few slashdot readers on homebrew/reference/open hardware right now; feel free to hit reply...)
The VR3 isn't perfect. It has many things wrong with it. But it's the flag carrier for development of PDA systems Linux-style. Well, handhelds.org wins for repurposing the iPaq hardware, but Compaq isn't corporately dedicated to supporting Linux on that PDA.
(Insert rant about what "Linux" really means here. Imagine I claimed that glibc+kernel was the most useful definition right now.)
OTOH, if you just want 32-bit Unix performance, you're going to be rather envious of your cubemate who bought a Dell OptiPlex GX 150 P3/1.13 512M 80G for the same price, and plopped Debian on it....
Signed, :-/
An Ultra 10 owner who switched from Solaris 8 to Debian/SPARC
Why yes, I do.
(OK, now that I've established my credentials... :-P )
You folks should react to new products differently. New Linux products are an opportunity, not a threat.
Let's do iPaq vs Zaurus first.
The Zaurus hardware architecture is substantially similar to the iPaq. Even if the kernel sources are maintained separately, you should be able to run the same distributions on the the Sharp as on the Compaq (once we do any needed X server changes). So if you're really dedicated to the handhelds.org community, this gives you the opportunity to choose between two hardware vendors and devices to run Familiar on. Competition is good, right?
Now, what about handhelds.org/familiar vs Zaurus Linux? Well, there's still a lot of lingering questions about the efficacy of the X11 architecture for handhelds. Sharp's commitment to QTE means they've spent a lot of resources on building a nice environment on top of it. So for you, the opportunity is to let Sharp spend a lot of money finding out how well the QTE architecture really works. And if they're right, because this is Open Source you have the opportunity to take the basis of their code and use it yourself. No risk.
What about the Java angle? Jeode isn't Open Source. But PocketLinux is. (And appears to have some very active development lately.) If Jeode is doing some things right, PocketLinux gets to pick up the best of their ideas for free. The opportunity is to explore the viability of Java and alternatives for Java application architectures for handhelds, and again, at no cost to you.
Stop thinking of yourself as a member of the handhelds.org community, or the PocketLinux community, or the Agenda VR3 community.
Start thinking of yourself as a member of the Open Source community---with particular interests: handhelds, information management tools, multimedia, task mobility....
We don't know what the right answers are to all of the hard questions that face us; we don't even know all the questions. But we can share our results, change direction, and work on parts of the problems as we ourselves see fit. When companies produce Linux products, they're another research staff and contributor to this, not a dictator. That's the value proposition of Open Source in emerging technologies.
In wrong place - it's even worse :-//
Don't you mean: :-|
Java is a marketing buzzword that covers a variety of technologies. Quoting http://java.sun.com/java2/whatis/:
Notice how they don't say "Java is a language..."?In the Java 1.0 days there were essentially three things referred to as Java: the JVM, the language, and the standard library. Oh, and maybe something about delivery of applets through sandboxed bytecode. Four things Sun wanted you to think of for the term "Java". Now there are a zillion. Soon, there will be a zillion and fifty.
OK, OK, those aren't at the same architectural level as the big three components. But "Java" has become increasingly vague, and don't think Sun isn't encouraging this. They want non-directed feelings of goodness associated with whatever's in their (proprietary) platform this week.
If what people wanted from Java was just a language, in the traditional view of what a language is, gcj would have taken over the world by now.
No, Linux is originally Linus's terminal emulator project. Then it was a replacement for Minix, a free Unix operating system that people could run on widely available, inexpensive desktop hardware. And in that role, it was primarily used first as a desktop box; only later (think post 1.0) were people starting to deploy it widely as a server platform.
Also, some Linux platforms run XIP. It's fairly easy to make the kernel itself run in place on linear ROM; just a few linker script tweaks. The Linux VR kernel also supports XIP for chosen exectuables and shared libraries, thanks to Rob Leslie's work on XIP for cramfs. On a file by file basis, you get a choice between uncompressed execute-from-ROM via MMU, or cramfs's block-by-block compression for executables you don't expect to be paged in as much.
Yes, Unix systems tend to think of the world in terms of files. But for specific, chosen access styles, under the hood the files can be accessed just as efficiently as a fileless PalmDB scheme. Unix gives you a choice of how to do it, and you're not stuck with it; you can still read() and write() to files you're usually treating as memory-mapped databases. (With whatever synchronization you deem necessary; PalmOS doesn't have concurrent access synchronization problems because it, like DOS, only supports one program running at a time.)
Actually, WinCE has support for XIP as well, but I don't know enough about it to post anything authoritative.
Sure, a company could take the Linux kernel and tools and write a Palm-esque interface for it, and rewrite the guts enough to be naturally resource-based XIP.
Like this?
And every company is going to have their own "redux Tux", which means you won't be able to generate a single executable file that you can throw on any device, the way you can with a Palm.
In other words, desktop Linux people should give up because a) you can't just throw a Windows or Mac executable on any machine and expect it to work. In fact, Apple should give up as well.
Nah. Diversity is a good thing. It's what got Linux here. It's what got *BSD here. We wouldn't have Gnome or KDE if they hadn't decided to dump Motif and Athena.
Think of Bluetooth as USB without wires. Ignore the hypemeisters who want to use it to deliver locale-enhanced portal services, or whatever it is they're trying to sell now.
If Bluetooth succeeds, it will be as a cable replacement first.
BTW, the MMC interface is quite simple; it's the kind of interface you could build in a second EE course on design with microcontrollers. Much simpler design than CF.
I ran around running my Linux cross-compile benchmark on a bunch of Sparcs. The 1G RAM, 440MHz Ultra 10 checked in with performance that was strictly worse than the 320M 450MHz iMac DV+. The 500MHz Blade 100 was around 10% better. Now, these figures are probably a tad low; I realized after the fact I was using an SMP-enabled kernel, and that adds overhead even on a single-processor machine. So credit them with another 10% until I get publish-worthy numbers. The Sparcs are still crushed by the 733MHz P3 el-cheapo Dell Optiplex, and the (badly-configured) Athlon 1200 has nothing to fear.
The Blade 1000 is a different beast. It's a real workstation, with 8M caches---can't get that in the beige box x86 world, and there are a lot of workloads that are just screaming for it. I don't have numbers yet, but I expect they'll be much more competitive. Of course, for $15-20k for a dual processor box, they'd better be.
So why buy a Blade 100?
By the way, newer kernels improved the Mac performance substantially, and SMP provided around a 60% speedup on the tests on the dual 533MHz PPC. I think I know where to borrow a dual 800MHz PowerMac, which should finally beat the crap out of the Athlon 1200. Of course, now I'm curious about dual Athlon performance, but I dunno if I really need a new machine just to run some benchmarks...
I agree that IBM in the server space is the classic example of a systems company that works. But IBM's services are far more broad than what Apple provides; Apple isn't in the business of producing end-to-end products and services. And even IBM lately is waving the unbundling banner with their Linux push. Vertical integration can provide great benefit to customers, but often it's used to extract high profit margins from customers once committed---and you can ask IBM's customers about that.
I don't think my analysis is patently false (obviously). The cloners did use board designs incorporating R&D from Apple, and that was negotiated. Apple could have named an appropriate per unit price to compensate. But then there's PReP. With PReP and CHRP, IBM and Motorola provided significant amounts of engineering and the reference designs, if I recall correctly. Motorola sure wanted to get more PPCs out the door, so they were highly motivated to produce designs for motherboard manufacturers.
Apple's goal with the cloners was also to look like they were open. There was significant corporate misgivings about sole-source hardware, and with Microsoft pretty much destroying every other vertically integrated personal computer hardware manufacturer, it left Apple vulnerable to these kinds of worries.
In a perfect world, the cloners would have been encouraged to innovate on the hardware side as well, of course. But I agree with your position that the cloners got their hardware designs far too cheaply, and had no reason to push.
Power Computing put themselves out of business by their actions, but that happened because of poor licensing contracts, and a complete misunderstanding of their relationship to Apple. But Apple lost a real opportunity to be the benchmark manufacturer and software licensor for an industry, rather than a lone wolf.
If Apple weren't a software company, they could just jettison all the expensive MacOS development work and produce translucent, elegant, highly certified and tested x86 machines, and save a bundle.
If Apple were a hardware company, they wouldn't have lost so badly when the clone makers gave Apple's customers what the customers wanted---inexpensive, powerful machines that ran MacOS, without logos, frogdesign, or ad campaigns. Instead, Apple was forced to reconsider what made them competitive, and yanked all the software licenses.
Back in the days of PReP (a joint IBM/Motorola/Apple standard for PowerPC motherboards), Apple stonewalled on support, claiming there were problems getting MacOS to run on PReP hardware---they couldn't get it to work without having Mac ROMs, and there was some problem with *that*, and etc etc etc. A small Swiss software company (I believe called Qix) demonstrated MacOS running on PReP hardware, and IIRC Apple threatened them into little pieces. Later, Apple sorta endorsed CHRP, a successor to PReP, this time with a spot for those all-important Mac ROMs to live. But Apple never shipped MacOS for CHRP; this was the era when Apple was retaking control over hardware that could run MacOS. Of course, all that talk about engineering requirements for Mac ROMs in hardware turned out to be bullshit; the iMac next to me has OpenBoot ROMs, and loads the Mac ROMs from the hard drive.
Apple's work on PReP and then CHRP, and their commitments to supporting MacOS on those platforms led to great hopes for a commodity market in PowerPC motherboards, especially among Linux weenies like me who wanted widely available, appropriately priced non-x86 desktop machines available. Apple's broken promises are a part of why more of you aren't running Linux on non-x86 machines. But hey, at least Apple got to keep their software locked up.
Locked up? Well, maybe that's the wrong concept. Let's think of Apple-branded hardware as a Really Big Dongle, a copy-protection mechanism for MacOS. (The CPU incompatibility also keeps them from looking like they're competing with Microsoft, which makes Microsoft happy.)
Here's a fun experiment. Sit down with the parts list for a modern Mac and compare it to a well-built, well-designed Windows box from a first tier vendor, like Sony. The two machines may even have a lot of identical parts, now that Macs have PC133 memory, PCI, AGP, IDE hard drives, etc. Once you get done, add ~15-20% to the price of the PC to compensate for the generally better quality and design of Macs (if you believe that.)
If you do this across Apple's product line, you'll notice price differences anywhere between $75-100 for iMac-like machines to several hundred dollars on the high end boxes. Part of that margin is what pays for R&D, and in particular, OS development. So in some sense, Apple prices their OS by the capabilities of the hardware it runs on. Microsoft can only dream of this kind of profit maximization through differentiated pricing. Oh, and the license isn't transferable; you end up buying a new MacOS license fee when you buy a new Mac. That's how Windows OEM licenses are supposed to work; there's still a fair amount of piracy of Windows onto beige boxes, but Apple avoids that too.
Anyway, a potentially important reason why Apple hardware retains value is that a significant portion of original hardware cost is actually paying for the MacOS Dongle. Even as the cost of the hardware depreciates, the price of the ability to run MacOS does not depreciate as sharply.
In addition to all the random female-depicting porn you're familiar with, I get aluminum market newsletters, British SMS-music-info-service announcements, and some very tasteful Swedish news mailings. Oh, and for a while nop@nop.com was listed as the contact address for a gay personals service ad in Portugal. The letters I got were very sweet, but my wife still thought it was funny...
My favorite is when people buy unlock codes for commercial software, giving my email address. I've got a whole folder full of registration codes that I didn't pay for and will never use....
Oh right, back to opt-in. So here's what's going on.
- When spammers say "opt-in" they mean that at least somebody typed an email address into a web page somewhere.
- When spammers say "double opt-in" they mean the horrible, onerous, business-destroying requirement to confirm that the person receiving mail at an email address wants to receive their mail. Anti-spammers prefer to call this "verified opt-in", and I like that term better, but it doesn't matter what you call it.
So when somebody types nop@nop.com into the signup for Goatmail (intentionally goating me or not), a verified opt-in system sends nop@nop.com a message saying "hi! hit reply to this message to confirm and enter the wonderful world of goats!" With non-opt-in systems, I'm in Goatland without any further delay. Sort of like when my "friends" sent all the "I'm interested!" postal reply cards to the Navy recruiters AND the dental post-doc programs with my address on them. Took years to get rid of them.But I digress again. Here's the summary:
- Unverified opt-in means someone wishes for an email address to receive spam.
- Verified opt-in means the recipient of mail sent to an address wants spam.
That clear things up?"oh sure, we're going to (embark on lengthy silly task) because that way it will be Free!! It will r0x0r!!"
"Well, how far have you gotten?"
"We have a sourceforge site and some PHP and somebody did a killer Flash intro..."
Easy to talk big on slashdot....
The Dragonball CPU used in here doesn't have an MMU, which means that you don't get all kinds of things like memory protection, demand paging, fixed address executables etc. Oh, no fork() either. No glibc, so porting gets harder too.
Don't get me wrong; ucLinux is still very cool, but it's not in the same league as the Agenda VR3, VTech Helio, or mono iPaq. Of course, they're all at least double the price....
Why do you want multiple programmer-visible allocation models?
Most language systems have only a single model of memory management. For instance, C++ as commonly used has malloc-new/free-delete; anything beyond that is up to all of the libraries and user code to agree on. You can have endless fun with C++ class libraries fighting over which smart pointer scheme and container deallocation policy is going to win.IMO one of the best multiple model systems I've used is in Modula-3, where normally all references are "traced"---automatically managed. But modules marked unsafe could manipulate untraced references and do all that pointer arithmetic that C jocks think they can't live without. Of course, there was a lot of peer pressure not to mark your modules unsafe unless there was a good reason, which made people carefully consider whether they really had to do risky things to get their part of the job done to the required performance standards.
Let's get to particulars. Squeak's collector is generational. Object memory is divided into "young" and "old" objects. Since the vast majority of objects are used once and forgotten, we don't need to scan "ALL" the objects to do most collections. Eventually, yes, we need to do a full collect, but this is fairly rare. You're right that this is problematic for realtime apps, and I don't know what people do about it. But given the frequency my Linux and W2k boxes decide to go thrash a little due to background tasks, I suspect it's acceptable for other apps.
Btw, the GC stats from the random image I pulled up claim 6507 minor GCs at average 9ms, and one full GC (which I explictly triggered) at 627.0ms.
I don't really feel like getting into the whole "GC is good/bad" flamewar; there are a lot of subtle issues on both sides, and I don't think I can argue either side with authority.
Blah blah smalltalk/scheme/etc are strongly typed and latently typed blah blah.You're right, in that there are not tools commonly in use to allow programmers to specify that arguments must conform to particular protocols. (You don't want to say "is an instance of class Collection" because subclassing is not subtyping; you want to say "must support the add: and remove: protocol"). That being said there are various type inference systems people are playing with.
Yes, and this is a serious weakness of most language environments in current use. A lot of energy and dollars have been spent on trying to provide collaboration tools for static languages like C, and even there the results haven't been satisfactory. Witness all of the CVS replacement projects and commercial source control tools.Smalltalk's changeset tools are better than nothing, I guess. Other people in the thread have mentioned various multiprogrammer tools for Smalltalk, like ENVY; I haven't used any of them, but I think they're the rough equiv of CVS. That's not good enough.
Extreme Programming originated as a methodology for supporting multiprogrammer collaborative projects in Smalltalk, so it's not like the environment keeps you from doing this, especially if you have decent policies in place.
Once the Squeak people come up with a good module system, I suspect the collaboration issue will significantly improve.
As far as language-level support for multiple programmers goes, the best examples are mud implementation languages; I work on MOO, which might be a good place to mine for ideas.
True of many languages in common use, of course. C and C++ force you to have definitions for all symbols referenced at link time, so what people end up doing is writing stub functions defined as die("i'm not written yet"), which gives you exactly the same failure mode as an incomplete Smalltalk program.The Squeak environment will complain loudly at you if you compile code that references method names that aren't defined anywhere.
Those two paragraphs are just a flail at what I'm guessing you mean there. With such a vague condemnation of Smalltalk systems and the people who use them, I don't know how to respond to particulars. If you meant something else, please follow up.
Yes, and I think I ran into this one time. Luckily, new instance variables are initialized to nil, so you won't get the disasterous results of following uninitialized C-style pointers.IMO there aren't any entirely satisfactory constructor systems in any language I know; I've been bitten by them all. C++ goes to great lengths to try to address these issues, and as a result ends up with a great deal of conceptual complexity, and that cure sometimes feels worse than the disease.
If you did, we could discuss those issues rather than handwaving them. OK, OK, yes, this is slashdot and not the right medium for long conversations, and I'm getting tired of typing too. Smalltalk is a pretty good prototyping language. Whether it's suitable for a given set of people to use to build a particular mission-critical or commercial-grade application is highly dependent on local circumstances, as is the choice of any other language. Because of its strengths and weaknesses, Smalltalk has been used successfully to produce many bespoke mission-critical applications; for lots of reasons, especially runtime licensing and business models, it has not been successful as a shrinkwrap dev environment. Its poor fit into Unix's process model hasn't helped either. (Lisp and Java have similar problems btw.) I think that's too strong. At this point, systems that in the past were condemned for bulk/model issues, such as Common Lisp, are dwarfed by Java. I mean, if you thought CL had a bunch of thick manuals, you'll be appalled at how heavy the books describing the contents of the Java 2 "Standard Edition" are.I'm on vacation from Squeak. I got burned out banging my head against some of the modularity issues, and frustrated by how hard it was to build "conventional" user interfaces in it. I can zap out a simple button/entry/list/dialog box UI in Lua FLTK much faster than in either of Squeak's two UI systems. I'll probably return though. There's something really attractive about Squeak's environment, goals, and its incredible development community.
I'd make some kind of Java analogy here, but there isn't a good stand-in in the analogy for X.
In this case, arguments for "proprietary" software licenses are arguments for the use of government force on the behalf of copyright holders. I mean, all this talk about "intellectual property" is eventually backed up by state power (with guns as the final resort), right?
That's not to say that I think enforcement of copyright and contract law is necessarily or entirely a bad thing. In fact, we get a lot of good out of copyright. But I think we need to look at actual causes, effects, benefits, and costs when discussing these issues rather than taunting each other with "look, I have more liberty than you!"
My meter for "be careful, somebody's trying to pull a fast one" now trips when the discussion's terminology gets "Intellectual Property" added to it. There is no such thing in the law.
There are legal mechanisms for patents, trade secrets, copyrights, trade marks, service marks (and a few others), but none of these legal mechanisms are as strong or complete as those laws related to real property. And that's as intended; real property and intellectual creations have very different characteristics.
People who are pushing the term "intellectual property" into arguments often are indicating their desire to make the legal controls[1] over information creations to be as strong or stronger than those over tangible property. So that not only means eliminating fair use and expiry, but also the creation of new categories of government control mechanisms for those things that inconveniently don't fit into the existing legal structures.
[1](Note "controls"; "protections" is another attempt to shift the terms of the debate.)
The great thing about sniffit is that other people will, uh, install it for you on Internet-exposed machines...
Introduction to Building Projection-based Tiled Display Systems
Nice pictures inside, but of course it can't compare to actually seeing a massive OpenGL fractal bouncing around a huge crisp display...
nop@bandwagon:~$ ls -l
-rwxr-xr-x  1  rootroot   887712Mar2517:35 
nop@bandwagon:~$size 
text data bss dec hex filename
869332 13232 15132 897696 db2a0
That's not to say that an 800k libc on x86 isn't big. It gets even bigger on more RISCy platforms like MIPS. The Agenda people are sticking with a patched glibc-1.0.3 until they can decide how to rationally compile out features.
In my opinion (which is not so humble after a lot of embedded Linux hacking), Linux is defined as not just a kernel, but also by libc. I can live with all kinds of wacky new kernel features as long as the C library uses and hides them from me. But changes, even bug fixes, to libc can break code in all kinds of unexpected places. Remember when Netscape needed a very specific libc version in order to cope with netscape's, uh, issues?
The people who work on glibc deserve a lot more respect and visibility.
Actually, now that I think of it---what's the refresh rate at 1280x1024?