I'd take a Tungsten E over any Zaurus 5x00. I'd probably go with a Zaurus C760 over the T|E, but that's about it. The 5x00 series have the *worst* screen I've seen on a PDA, I'd much rather have the bright, crisp and bigger (320x320 rather than 240x320) screen of the T|E. Hell, I'd prefer the 320x480 greyscale screen on the Newton 2100. If it's not going to be the best screen, it may as well not suck a tremendous amount of power...
That is precisely the issue for most people. They want something that works.
The attitude most free software advocates take is very different from that. They provide reasons like Freedom- like you mention. That attitude combines poorly with companies like Sharp, who use free software chiefly to save money on a license, among a couple other reasons. They want someone else to do the work for them. Now, I have no problems with commercial companies using OSS and not giving back (though many do, not saying Sharp doesn't)- if a developer doesn't want their stuff used to make money, they should use a license that specifies thus.
Looking at the Zaurus line of PDAs illustrates this well. On some fronts, they are nice devices- but in a lot of others ways they are not. I could go into detail about this, but who knows who is still reading this thread this far into its posting. There are a lot of crappy aspects to the Zaurus and other Linux handhelds, even though the hardware is pretty nice.
A short summary: 1. The Zaurus feels slow, even with a PXA255 XScale running at 400 MHz. Lots of redraw sluggishness. Apps take a long time to launch, sometimes up to 12 seconds. The official work around for this is to just have the application running all the time (ha!), so that when you try to run it, switching to it only takes a second. On a platform like PalmOS, that might not so bad, but applications often take up a number of MB.
2. Memory usage. Downright obese. My Zaurus C760 takes up 18 MB of RAM on a fresh boot. Some people respond to this with "Run X11 not Qtopia!" That will be a solution when there are good PDA app for X11.
3. A lot of sucky apps. There are some gems- Opera, NetFront are two. The apps by TheKompany are nice. Every platform has sucky apps, but on the Zaurus, the case is often the sucky apps are the only option. Yeah, if it's free I can't complain- but very few commercial developers are drawn to the Linux PDA because so few people have them, sales are so small.
4. Qtopia / Qt Embedded isn't the best thing for creating PDA applications. The API wwasn't designed for a stylus driven machine. A lot of the time this isn't an issue, but for a number of things it becomes a problem. Qt/E makes a lot of things you can do on Newton OS, PocketPC and PalmOS very, very hard.
5. I imagine it isn't a huge problem for other folks, but for me it is- there aren't any good notetaking apps for the Zaurus, whether we're talking about Qtopia or X11. There also isn't any handwriting recognition, only crappy character recognition.
I was using gopher some 3 months ago. Believe it or not, a university was still using it for their people search! I can't recall who it was. Although, around a year ago, Macalester College was using it for their people search. heh.
ahhh, gopher. I used to use it a ton. Back in the day, the U of MN would run a free gopher client service into which you could telnet. I used to know of an 800 number that when dialed would just yield a telnet> prompt... Must've been for some companies agents in the field or something. But between the magick telnet> and the free gopher client, I was a very happy 12 year old! Mind you, this was back in 1992, far before most of you whipper snappers got a copy of Netscape 3.0 (GOLD!@$) from your ISPS.:)
Re:Well, duh. (and other fun uses for RFID tags)
on
The Trouble with RFID
·
· Score: 1
Heh, exactly! Where did I leave my keys? My glasses, brain or condoms? It's all tagged, man.:)
I wonder if getting an RFID tag scanner is impossible for consumers...
Well, duh. (and other fun uses for RFID tags)
on
The Trouble with RFID
·
· Score: 2, Insightful
Who didn't figure that RFID tags will be used to track us- the consumers? Hell, that may be even a better use for them than inventory tracking... They get about the perfect picture of what products we use, when and to an extent how. The marketers wet dream. And of course the definition of propriety will be stretched, bent and broken during the courtship of RFID tags.
Now, I on the other hand, have a want for them. I think they could be fun to hack around with. That is, I want my PDA to be able to read tags, and then I'll get a bunch of them. I'll tag my house up, so that I can get location-based alerts. The kind of thing GPS would be too big and clunky- and not accurate enough- to do. I can come up with all sorts of fun things to use RFID tags for in my own life that have nothing to do with being "targeted" better.:)
Then you won't need libc at all. Linux (really gcc) has that capability, even if you don't want to use it.... just like you can "link" in the whole, huge.NET runtime- or perl, python, smalltalk runtime- in an executable file. 20 MB hello world apps own me!:)
Heh. I'm going to write an article about "Linux's biggest oversight." Why should I need libc, or even worse, libc++ to run KDE or GNOME? SICK! WRONG!
Unless it's written in assembly, with no calls to any library, I won't run it. The only thing allowed is calls to interrupts or BIOS. DOS, here I come! (back)
first of all, you can get a linker for.NET if you want. like similar tools for perl and python, it packages everything up that you need into one exe. this took 10 seconds to find via google. Perhaps Joel should try google next time. What is this, ask slashdot?:)
there is nothing different about the way.NET does this and any other system. Sure, there isn't a way to link it all into one.exe file, but that may come in the future. that is, in perl and python (among others) that was the case at first- you had to download a big runtime and possibly other libraries to get your app working. these days, you can distribute your app in that way- a 20KB download of your.pl files,or a big-ass executable that integrates all the requisite libraries, VM/runtime system, etc etc. however, this often ends up giving you a file that it almost as big, but at least, it is a little simpler on the user.
again, Java does this too. If i have a.class file or jar, there isn't some way to encapsulate it all into one double-clickable executable file that I can share. I have to have my users download a big package, the other libraries, and then my app..NET is no different, and there is no reason to expect it to be. joel gripes, saying that microsoft will come out with a new version every few months. just like with new versions of perl, python or java, there is no reason that the user would neccesarily have to have the brand-spankinest newest version. if your app requires it, you make it a requirement. put it on the CD, and say- install this if you don't have it yet. big deal. if you were smart, you'd write your apps against the most common verison-.NET 1.0 or 1.1 for now, just like a lot of Java apps are still written for Java 1.1, not even Java 2! Most folks don't write apps for the newest Java, 1.4.x unless they really need it.
what the hell is so different about how.NET does it?
Well, waaa- my OS has even more control than yours. It is open in ways that a system like your average Linux install can't be, at least, not unless it was all rewritten in a more flexible language.
I can reinvent my environment in a few seconds- no need to sit through a long recompile cycle, a reboot or software restart to run the new version; it's just there.
You never really had the opportunity to use it in the first place, so how can you credibly claim it to be an option you've rejected?
Read the post, man. I said I rarely use the recording funcitonality, usually doing things programatically. I have made recorded AppleScripts- usually to do repetitive interaction with a few apps so I don't have to, often moving data between them. I didn't say that I rejected this method, nor did I say that I have never used it.
Any "position" I have regarding this is based on my experience and my uses. I don't claim that my usage of AS/OSA represents what everyone does, but unlike you, I am not saying that everyone should do things my way or that I have discovered the one true way to do things.
But my questions remains- how do you propose to replace programatic use of AppleScript in the ways I've described? I have presented concrete examples and valid questions, but you just tell me that I've never done it the "right" way, which puts me in a poor position to have an opinion. That doesn't make any sense, man.
That's one example only, and a fairly bizarre one at that. I didn't say that there weren't uses that precluded recordability, and I'm not sure I would describe you as being in AppleScript's target audience in any case.
I am not claiming that that example is representative of what most joe-espresso mac user is doing. I could list more examples of times where you are pulling data out of one app and pushing it into another, examples of scripts that do no interaction with the GUI.
Are you saying they should take that out of AppleScript just so that you can stick to some concept of recording purity?;)
Again, your example is atypical and not particularly relevant here.
How is it atypical? What is typical and relevant? Let me guess- it happens to be the way that *you* use AppleScript? My example was one of many similar ways I have used AppleScript programatically. I am not saying most Mac users are writing code to customize their computing environment with AppleScript, but it is an example that doesn't make sense to be recorded.
Python only comes with the Developer Tools CD, IIRC.
Python 2.3 comes with 10.3, not on the dev tools CD. I just checked on my girlfriend's iBook, who doesn't have the dev tools installed. I don't have access to a 10.2 machine, so I can't say for sure, but I'm pretty sure it was there without the dev tools- I did some scripting for someone with a few 10.2 machines who wouldn't even know what the developer tools are.
I guess nothing. It's not first-class support for the language though, which was my only point. I may not want to support issues Apple may or may not have with Python/PyXML/whatever. Maybe you're interested in doing that, but I am not.
Ah, the classic open source dilemma!
You want it all, but aren't willing to do a lick of work to get it.:) And in this case, the amount of work is rather slim- Python is already there, and adding the PyObjC stuff is a few MB of an install. The community already seems to do a decent job at supporting it. Even if Apple shipped an objc bridge with OS X, it is unlikely they'd provide the level of support you seem to want, at least, not unless you had some expensive support contract with them.
Possibly because so few applications thoroughly support recordability? So the first time you try, you see it isn't there, and the next time, and so on, until finally you just give up and code it manually.
Nope. The reason I only rarely record my AppleScript is that I often can't record what I want to do. And not because the poor support you claim, rather because there often isn't a way to do it in the GUI. It's the wrong style, at least for what I'm usually trying to do.
For instance, one way I have used AppleScript is to make a little window/app switcher for Squeak Smalltalk, a language that doesn't use the Carbon or Cocoa APIs in its GUI, other than to use as a fancy framebuffer. Squeak has its own windowing system. Anywho, I want to be able to switch to the "real" Mac apps I have running, so I wrote a ditty that brings up a menu with the apps running in Squeak and in Mac OS, and when selected switches to it. The AppleScript used involves asking the Finder what apps are running, and what windows are a part of those apps, information about apps and windows, switching to them, etc etc. Those actions are not the sort of thing I really could record, nor would I want to. This example is pretty representative of what I do with AppleScript. I call out to AppleScript and get a return value, which I may or may not parse and use in my program.
But let's say I just had a task I wanted to be done over and over again. I may record parts of it, and then edit the code, put it in the loop, etc etc. I have never had a problem with doing things this way- no matter if the OSA has any idea about the semantics of what I'm doing. I don't care that it knows what I am doing in the end, just as long as it does it for me.
It isn't accessible because the application has poor support for recording. Ideally, *everything* that you do with an application would be recordable.
Sounds like a fine dream, but not one that makes a whole lot of sense for some actions. Using my example, how do you think AppleScript or the app should support those kinds of things? Have some far more elaborate system of visual programming? Or just have all of those more programmatic actions be in a list that I can get in a menu? If so, why not just use the Dictionary?
Yeah, but I was talking about first-class support, with tools that are installed with the OS and/or developer tools CD, and with docs that are aimed at Python coders, and so I can release a distributable and not make a half-million Mac users try to figure out how to install Python and PyObjC and so forth.
I haven't used 10.3 that much, but in 10.2 you got Perl, Python and Ruby installed by default. What's so hard about having your users install a framework first, and then double-clicking your app? After all, this is OS X, not Linux or Windows. One should be able to drag PyObjC.framework to the frameworks folder, either the local user's frameworks folder or the system-wide one. Or, you could put it in your app's bundle, then they wouldn't have to ever see it. You don't even need to use an installer script.
Everyone wishes their favorite pet language had full first-class support in their favorite OS. There really isn't an answer to this. The other guy wants perl. Other folks want Ruby. I wish Smalltalk runtimes shipped at OS X's core. I mean, Objective-C is just C plus Smalltalk- a natural fit! If that's what you want, do it; OS X opens up a lot of ways to give your users what they want and do it easily.
A few objections on your post, at least from my standpoint.
I really like the AppleScript system in the Mac OS. I have always found that most apps support AS scripting decently. However, I have no idea if support for recording is lacking in some apps- I only record a macro *very* rarely.
What I like about the OSA- Open Scripting Archtecture, of which AppleScript is the default language- is the ability is using it to call into apps that otherwise are isolated from my program. I like to be able to eval a line of AppleScript and get a string with the returned value; or, in Perl, Ruby, Tcl, JavaScript and others, I can call into those commands directly.
See, AppleScript is but one language in the OSA. Any language can hook into it, giving it AppleScript's powers, without the need to ever touch AppleScript. I love the OSA and what AppleScript provides, but the language itself is not my style.
Why should I be recording my scripts? A lot of what I do with AppleScript isn't neccesarily accessible with a straight-forward button or other GUI action. Which is why I access the Apple event directly.
A Python-Objective C bridge has been around since OpenStep days.
If you think AppleScript/OSA lack supporting-apps, it's good you don't use Windows with the WSH.:)
I've used Linux for a longer time than most of the slashkids in here have known how to read. Like a lot of Linux users, I went through the silly zealot phase, but luckily, matured enough to make my way out of those woods.
NeXTSTEP and then OS X, for me, was Unix without the hassle of Linux. Way too often on Linux, now and then, I spend more time dicking around with the machine- screwing around with libraries, configurations, all sorts of stuff- than I did doing "real work." That was all fine and dandy when I had an abundance of free-time, prime to be wasted. Not to say that learning- especially enjoyable learning- is a waste of time, but for me, configuring, installing, and doing all sorts of other maintenence on my Linux system is about as much fun as maintaining Windows. When I want to work I want it to work. Sometimes, I may go back on the random weekend to do that 'under the hood' stuff, but I don't want to *have to* spend time under the hood just to keep it running.
With OS X, I had the best of both worlds. I had oodles of stuff to tinker with, to my heart's content- and a lot of it is totally new to an old DOS and Linux user, a brave new world full of all sorts of fun stuff. I can go in and spend time under the hood as much as I like. But, when I haven't the time or the desire to do so, it just works.
For those of you with so much free time as "playing around" with Linux constitutes most of what you consider as using your computer- more power to you. Learning is fun and never a waste of time. But for those of us who want the perks provided by Linux or another Unix-like OS but with a number of positive advantages that impact silly things like "productivity", we have OS X.
How much does Apple have to give back before they make good? Is there some percent, some KLOC in code coming from Apple that makes them a good member of the OSS community?
Or is it that you're just jealous? You don't happen to care about what Apple has shared- Squeak, GameSprokets, KHTML improvements + WebCore + WebKit, Darwin, QuickTime Streaming Server, and a host of other stuff? You want the Quartz, Aqua? You want Apple to open source what makes a Mac a Mac, so you don't have to spend $50 more on getting one yourself? Too entrenched in having a l33t PC, or possibly too embarassed to just suck it up, be a man and buy a Mac?
Mario Kart is a bad ass game, regardless if you're 6 or 16 or 60. I mean, a game doesn't have to be a sports game or something violent to be "for adults."
I couldn't give a rat's ass about gran turismo or the newest rpg. my roomate has a GC and I've not been left wanting... other than knights of the old republic...
Qtopia has wasted years rewriting the low-level graphics stuff but doing no better than Palm or PPC on apps.
And not just no better, but quite a bit worse. Heck, I have found better and more available Linux/Unix adaptations for WinCE than for the Zaurus. It is easier to simply recompile a Linux app for the Zaurus, but a lot of those apps aren't usable on a PDA.
The right thing to do would be to develop an updated Newton-like environment (dynamic language, persistent database, XML data interchange, etc.) and not waste time with reinventing the low-level infrastructure
Huh! Are you my secret double or something?
That is the kind of solution I have favored, and the one I have been working on. The dynamic language is Squeak Smalltalk. THe persistent database is Magma, and object database system for Squeak. Some XML interchange- through XML-RPC and SOAP- but it isn't used as the storage format.
The system I am working on it is called Dynapad. You can see some new screenshots here. The wiki hasn't been touched in a long time, and it was rolled back (think their server had an issue, had to restore from a backup) and I have not had the time to redo it all. Mind you, work continues and I have done a lot since I have made a release. I will be putting out a new release within a week, it is long overdue.
Linux and X11 are fine for modern handhelds--they need decent, modern apps.
Indeed. I generally advocate for using a Linux kernel as what is underneath; Squeak itself can run as an OS, but with so many drivers and other perks of using an establish kernel, I can't see why not to use it. Dynapad can run on Linux under X11, DirectFB,/dev/fb, SDL, and Qtopia, though if I were creating a standalone system I would just use the framebuffer display mode for Squeak and Dynapad. It works quite well, and for one window, X11 is overkill.
And that's a real opportunity, because both Microsoft and Palm are sitting on their hands.
Again, you hit the nail on the head. Someting I have been saying for years. PDAs are a chance for us to start over again, and this time do it right. On Windows CE, the API is pretty compatible with regular Win32, but even so, it doesn't run regular Windows apps, so backwards compatibility isn't as compelling in that sense. PalmOS doesn't have the problem of backwards compatibility. They both had the chance to do it right, but they didn't. They didn't do it horribly, but still.
With the Linux/Qtopia situation, it is even worse. The community, as well companies like TrollTech and Sharp have done so little in this area. Even more so than MS and Palm, they had the chance to take that potential, the potential of creating a truly great, innovative (in the truest sense of the word) and forward look system. But they didn't. They took the easy way out. As a result, the situation is pretty crappy, and light-years from exceptional.
Don't forget- somewhere in the PalmOS 4.x series, Sony added a super primitive form of multitasking. Basically, all it did was allow one background thread which recieved only a tiny chunk of the machine's resources. All the thread could do is pipe data to the mp3 decoder chip on the lil guy's motherboard. that way, you could listen to mp3s *and* be in the addressbook at the same time! What an invention!
Hmpf! "PDAs don't need multitasking" they say! Ha! The PDA may not care, but I do! If I am going to spend anything more than $60 on something calling itself a PDA, it better damn well multitask, at least in a limited- but generally useful- fashion.
Similar to Sony's hack, PalmOS 5.2 has some very, very primitive two thread "multitasking," though in 5.2, the background thread is allowed to actually decode the mp3s and pipe it to the speaker rather than just to the decoder chip. Ooohhh, impressive!
Newton had something that might be called a "real PDA OS". The Sharp Zaurus has a "real OS that works well for a PDA".
Ha! It is about time someone else said that- so I didn't have to. I often bring up the fact that I want my PDA to have something resembling a "real OS," or at least, provide multitasking and some other so-called "perks" that I expect in an OS, be it on a computer that fits on my desk or in my pocket.
PalmOS users often say- why would you need a PDA to have multitasking? A PDA isn't meant to multitask. But that certainly isn't true. The first PDA, the device for which the term was invented- the Apple Newton- had most of the features of a "real OS," as well as a number of advanced features that a lot of so-called modern OSes running on desktops didn't have. In a lot of ways, even a 10 year old Newton outclasses most of the PalmOS units in circulation.
What Zodiac should have done is put a real kernel and OS on the Zodiac and run PalmOS as a guest operating system under that.
PalmOS 6 is the answer, at least, the answer most PalmOS users and licensees are looking at. Hopefully it'll be a good answer, but I have some reservations. For one, it it seems a bit silly that in apps for PalmOS 6, an OS that only can run on ARM CPUs (no m68ks!), the developer has to go out of her way to develop special code for native ARM, the default being to compile everything to m68k. And then they emulate the m68k CPU. Except, to my knowledge, PalmSource hasn't discussed what they're going to do about this in POS 6.x, 7 and beyond. Are they going to take a path like Apple's? Are they going to cripple users with performance, emulating 68k code for the next couple major versions, or will POS 6.x be the transition series, with POS 7 and beyond being native-ARM by default, without developers having to go out of their way to write ARMlets for only some selected functions?
The unfortunate thing about having the Zodiac run a "real kernel and OS" is that there really doesn't seem to be a good option for it. Sharp has proved that Linux+Qtopia really isn't ready for the privilege of running on a device in this class and category. Hell, there isn't even a way to use the Zaurus C7x0's Imageon 100 gfx chip, and I can't imagine the situation would be much different with the Imageon 4200 on the Zodiac.
With Linux, there is too much of a temptation for the company using it to just approach it like they're getting a deal, saving $15 per unit for the WinCE.NET 4.2 licensing fee. Linux could be very worthwhile if some company(ies) was willing to put a lot of time and money into Linux on the PDA, advancing the state of the art in a lot of areas. Sharp sure as hell isn't doing it.
The only option I can see is Windows CE. Now don't get me wrong, I like Windows CE; if only because it is the least sucky choice to be made for me as a PDA user. I'd rather be using NewtonOS, but that isn't much of an option for me anymore.:(
Slashdot Mirror
I'd take a Tungsten E over any Zaurus 5x00. I'd probably go with a Zaurus C760 over the T|E, but that's about it. The 5x00 series have the *worst* screen I've seen on a PDA, I'd much rather have the bright, crisp and bigger (320x320 rather than 240x320) screen of the T|E. Hell, I'd prefer the 320x480 greyscale screen on the Newton 2100. If it's not going to be the best screen, it may as well not suck a tremendous amount of power...
That is precisely the issue for most people. They want something that works.
The attitude most free software advocates take is very different from that. They provide reasons like Freedom- like you mention. That attitude combines poorly with companies like Sharp, who use free software chiefly to save money on a license, among a couple other reasons. They want someone else to do the work for them. Now, I have no problems with commercial companies using OSS and not giving back (though many do, not saying Sharp doesn't)- if a developer doesn't want their stuff used to make money, they should use a license that specifies thus.
Looking at the Zaurus line of PDAs illustrates this well. On some fronts, they are nice devices- but in a lot of others ways they are not. I could go into detail about this, but who knows who is still reading this thread this far into its posting. There are a lot of crappy aspects to the Zaurus and other Linux handhelds, even though the hardware is pretty nice.
A short summary:
1. The Zaurus feels slow, even with a PXA255 XScale running at 400 MHz. Lots of redraw sluggishness. Apps take a long time to launch, sometimes up to 12 seconds. The official work around for this is to just have the application running all the time (ha!), so that when you try to run it, switching to it only takes a second. On a platform like PalmOS, that might not so bad, but applications often take up a number of MB.
2. Memory usage. Downright obese. My Zaurus C760 takes up 18 MB of RAM on a fresh boot. Some people respond to this with "Run X11 not Qtopia!" That will be a solution when there are good PDA app for X11.
3. A lot of sucky apps. There are some gems- Opera, NetFront are two. The apps by TheKompany are nice. Every platform has sucky apps, but on the Zaurus, the case is often the sucky apps are the only option. Yeah, if it's free I can't complain- but very few commercial developers are drawn to the Linux PDA because so few people have them, sales are so small.
4. Qtopia / Qt Embedded isn't the best thing for creating PDA applications. The API wwasn't designed for a stylus driven machine. A lot of the time this isn't an issue, but for a number of things it becomes a problem. Qt/E makes a lot of things you can do on Newton OS, PocketPC and PalmOS very, very hard.
5. I imagine it isn't a huge problem for other folks, but for me it is- there aren't any good notetaking apps for the Zaurus, whether we're talking about Qtopia or X11. There also isn't any handwriting recognition, only crappy character recognition.
I was using gopher some 3 months ago. Believe it or not, a university was still using it for their people search! I can't recall who it was. Although, around a year ago, Macalester College was using it for their people search. heh.
:)
ahhh, gopher. I used to use it a ton. Back in the day, the U of MN would run a free gopher client service into which you could telnet. I used to know of an 800 number that when dialed would just yield a telnet> prompt... Must've been for some companies agents in the field or something. But between the magick telnet> and the free gopher client, I was a very happy 12 year old! Mind you, this was back in 1992, far before most of you whipper snappers got a copy of Netscape 3.0 (GOLD!@$) from your ISPS.
Heh, exactly! Where did I leave my keys? My glasses, brain or condoms? It's all tagged, man. :)
I wonder if getting an RFID tag scanner is impossible for consumers...
Who didn't figure that RFID tags will be used to track us- the consumers? Hell, that may be even a better use for them than inventory tracking... They get about the perfect picture of what products we use, when and to an extent how. The marketers wet dream. And of course the definition of propriety will be stretched, bent and broken during the courtship of RFID tags.
:)
Now, I on the other hand, have a want for them. I think they could be fun to hack around with. That is, I want my PDA to be able to read tags, and then I'll get a bunch of them. I'll tag my house up, so that I can get location-based alerts. The kind of thing GPS would be too big and clunky- and not accurate enough- to do. I can come up with all sorts of fun things to use RFID tags for in my own life that have nothing to do with being "targeted" better.
Then you won't need libc at all. Linux (really gcc) has that capability, even if you don't want to use it. ... just like you can "link" in the whole, huge .NET runtime- or perl, python, smalltalk runtime- in an executable file. 20 MB hello world apps own me! :)
Heh. I'm going to write an article about "Linux's biggest oversight." Why should I need libc, or even worse, libc++ to run KDE or GNOME? SICK! WRONG!
Unless it's written in assembly, with no calls to any library, I won't run it. The only thing allowed is calls to interrupts or BIOS. DOS, here I come! (back)
Man, it wouldn't be *that* hard to read the link. Did you miss that big banner at the top that reads "Deploy .NET w/o Framework"?
where is the surprise in this?
.NET if you want. like similar tools for perl and python, it packages everything up that you need into one exe. this took 10 seconds to find via google. Perhaps Joel should try google next time. What is this, ask slashdot? :)
.NET does this and any other system. Sure, there isn't a way to link it all into one .exe file, but that may come in the future. that is, in perl and python (among others) that was the case at first- you had to download a big runtime and possibly other libraries to get your app working. these days, you can distribute your app in that way- a 20KB download of your .pl files,or a big-ass executable that integrates all the requisite libraries, VM/runtime system, etc etc. however, this often ends up giving you a file that it almost as big, but at least, it is a little simpler on the user.
.class file or jar, there isn't some way to encapsulate it all into one double-clickable executable file that I can share. I have to have my users download a big package, the other libraries, and then my app. .NET is no different, and there is no reason to expect it to be. joel gripes, saying that microsoft will come out with a new version every few months. just like with new versions of perl, python or java, there is no reason that the user would neccesarily have to have the brand-spankinest newest version. if your app requires it, you make it a requirement. put it on the CD, and say- install this if you don't have it yet. big deal. if you were smart, you'd write your apps against the most common verison- .NET 1.0 or 1.1 for now, just like a lot of Java apps are still written for Java 1.1, not even Java 2! Most folks don't write apps for the newest Java, 1.4.x unless they really need it.
.NET does it?
first of all, you can get a linker for
there is nothing different about the way
again, Java does this too. If i have a
what the hell is so different about how
Well, waaa- my OS has even more control than yours. It is open in ways that a system like your average Linux install can't be, at least, not unless it was all rewritten in a more flexible language.
I can reinvent my environment in a few seconds- no need to sit through a long recompile cycle, a reboot or software restart to run the new version; it's just there.
so ha!
You never really had the opportunity to use it in the first place, so how can you credibly claim it to be an option you've rejected?
;)
:) And in this case, the amount of work is rather slim- Python is already there, and adding the PyObjC stuff is a few MB of an install. The community already seems to do a decent job at supporting it. Even if Apple shipped an objc bridge with OS X, it is unlikely they'd provide the level of support you seem to want, at least, not unless you had some expensive support contract with them.
Read the post, man. I said I rarely use the recording funcitonality, usually doing things programatically. I have made recorded AppleScripts- usually to do repetitive interaction with a few apps so I don't have to, often moving data between them. I didn't say that I rejected this method, nor did I say that I have never used it.
Any "position" I have regarding this is based on my experience and my uses. I don't claim that my usage of AS/OSA represents what everyone does, but unlike you, I am not saying that everyone should do things my way or that I have discovered the one true way to do things.
But my questions remains- how do you propose to replace programatic use of AppleScript in the ways I've described? I have presented concrete examples and valid questions, but you just tell me that I've never done it the "right" way, which puts me in a poor position to have an opinion. That doesn't make any sense, man.
That's one example only, and a fairly bizarre one at that. I didn't say that there weren't uses that precluded recordability, and I'm not sure I would describe you as being in AppleScript's target audience in any case.
I am not claiming that that example is representative of what most joe-espresso mac user is doing. I could list more examples of times where you are pulling data out of one app and pushing it into another, examples of scripts that do no interaction with the GUI.
Are you saying they should take that out of AppleScript just so that you can stick to some concept of recording purity?
Again, your example is atypical and not particularly relevant here.
How is it atypical? What is typical and relevant? Let me guess- it happens to be the way that *you* use AppleScript? My example was one of many similar ways I have used AppleScript programatically. I am not saying most Mac users are writing code to customize their computing environment with AppleScript, but it is an example that doesn't make sense to be recorded.
Python only comes with the Developer Tools CD, IIRC.
Python 2.3 comes with 10.3, not on the dev tools CD. I just checked on my girlfriend's iBook, who doesn't have the dev tools installed. I don't have access to a 10.2 machine, so I can't say for sure, but I'm pretty sure it was there without the dev tools- I did some scripting for someone with a few 10.2 machines who wouldn't even know what the developer tools are.
I guess nothing. It's not first-class support for the language though, which was my only point. I may not want to support issues Apple may or may not have with Python/PyXML/whatever. Maybe you're interested in doing that, but I am not.
Ah, the classic open source dilemma!
You want it all, but aren't willing to do a lick of work to get it.
Possibly because so few applications thoroughly support recordability? So the first time you try, you see it isn't there, and the next time, and so on, until finally you just give up and code it manually.
Nope. The reason I only rarely record my AppleScript is that I often can't record what I want to do. And not because the poor support you claim, rather because there often isn't a way to do it in the GUI. It's the wrong style, at least for what I'm usually trying to do.
For instance, one way I have used AppleScript is to make a little window/app switcher for Squeak Smalltalk, a language that doesn't use the Carbon or Cocoa APIs in its GUI, other than to use as a fancy framebuffer. Squeak has its own windowing system. Anywho, I want to be able to switch to the "real" Mac apps I have running, so I wrote a ditty that brings up a menu with the apps running in Squeak and in Mac OS, and when selected switches to it. The AppleScript used involves asking the Finder what apps are running, and what windows are a part of those apps, information about apps and windows, switching to them, etc etc. Those actions are not the sort of thing I really could record, nor would I want to. This example is pretty representative of what I do with AppleScript. I call out to AppleScript and get a return value, which I may or may not parse and use in my program.
But let's say I just had a task I wanted to be done over and over again. I may record parts of it, and then edit the code, put it in the loop, etc etc. I have never had a problem with doing things this way- no matter if the OSA has any idea about the semantics of what I'm doing. I don't care that it knows what I am doing in the end, just as long as it does it for me.
It isn't accessible because the application has poor support for recording. Ideally, *everything* that you do with an application would be recordable.
Sounds like a fine dream, but not one that makes a whole lot of sense for some actions. Using my example, how do you think AppleScript or the app should support those kinds of things? Have some far more elaborate system of visual programming? Or just have all of those more programmatic actions be in a list that I can get in a menu? If so, why not just use the Dictionary?
Yeah, but I was talking about first-class support, with tools that are installed with the OS and/or developer tools CD, and with docs that are aimed at Python coders, and so I can release a distributable and not make a half-million Mac users try to figure out how to install Python and PyObjC and so forth.
I haven't used 10.3 that much, but in 10.2 you got Perl, Python and Ruby installed by default. What's so hard about having your users install a framework first, and then double-clicking your app? After all, this is OS X, not Linux or Windows. One should be able to drag PyObjC.framework to the frameworks folder, either the local user's frameworks folder or the system-wide one. Or, you could put it in your app's bundle, then they wouldn't have to ever see it. You don't even need to use an installer script.
Everyone wishes their favorite pet language had full first-class support in their favorite OS. There really isn't an answer to this. The other guy wants perl. Other folks want Ruby. I wish Smalltalk runtimes shipped at OS X's core. I mean, Objective-C is just C plus Smalltalk- a natural fit! If that's what you want, do it; OS X opens up a lot of ways to give your users what they want and do it easily.
A few objections on your post, at least from my standpoint.
:)
I really like the AppleScript system in the Mac OS. I have always found that most apps support AS scripting decently. However, I have no idea if support for recording is lacking in some apps- I only record a macro *very* rarely.
What I like about the OSA- Open Scripting Archtecture, of which AppleScript is the default language- is the ability is using it to call into apps that otherwise are isolated from my program. I like to be able to eval a line of AppleScript and get a string with the returned value; or, in Perl, Ruby, Tcl, JavaScript and others, I can call into those commands directly.
See, AppleScript is but one language in the OSA. Any language can hook into it, giving it AppleScript's powers, without the need to ever touch AppleScript. I love the OSA and what AppleScript provides, but the language itself is not my style.
Why should I be recording my scripts? A lot of what I do with AppleScript isn't neccesarily accessible with a straight-forward button or other GUI action. Which is why I access the Apple event directly.
A Python-Objective C bridge has been around since OpenStep days.
If you think AppleScript/OSA lack supporting-apps, it's good you don't use Windows with the WSH.
Although, Apple did release a Perl - Objective-C bridge. I think it comes with 10.2's perl.
That is the way I feel too.
I've used Linux for a longer time than most of the slashkids in here have known how to read. Like a lot of Linux users, I went through the silly zealot phase, but luckily, matured enough to make my way out of those woods.
NeXTSTEP and then OS X, for me, was Unix without the hassle of Linux. Way too often on Linux, now and then, I spend more time dicking around with the machine- screwing around with libraries, configurations, all sorts of stuff- than I did doing "real work." That was all fine and dandy when I had an abundance of free-time, prime to be wasted. Not to say that learning- especially enjoyable learning- is a waste of time, but for me, configuring, installing, and doing all sorts of other maintenence on my Linux system is about as much fun as maintaining Windows. When I want to work I want it to work. Sometimes, I may go back on the random weekend to do that 'under the hood' stuff, but I don't want to *have to* spend time under the hood just to keep it running.
With OS X, I had the best of both worlds. I had oodles of stuff to tinker with, to my heart's content- and a lot of it is totally new to an old DOS and Linux user, a brave new world full of all sorts of fun stuff. I can go in and spend time under the hood as much as I like. But, when I haven't the time or the desire to do so, it just works.
For those of you with so much free time as "playing around" with Linux constitutes most of what you consider as using your computer- more power to you. Learning is fun and never a waste of time. But for those of us who want the perks provided by Linux or another Unix-like OS but with a number of positive advantages that impact silly things like "productivity", we have OS X.
How much does Apple have to give back before they make good? Is there some percent, some KLOC in code coming from Apple that makes them a good member of the OSS community?
Or is it that you're just jealous? You don't happen to care about what Apple has shared- Squeak, GameSprokets, KHTML improvements + WebCore + WebKit, Darwin, QuickTime Streaming Server, and a host of other stuff? You want the Quartz, Aqua? You want Apple to open source what makes a Mac a Mac, so you don't have to spend $50 more on getting one yourself? Too entrenched in having a l33t PC, or possibly too embarassed to just suck it up, be a man and buy a Mac?
If you want a Mac, buy one. If not, quit whining.
What's not to get?
Yeah, that original controller is huge. And a mess of buttons.
.. mmm.
gcn controller.
Mario Kart is for children? Heh!
Wow!
Mario Kart is a bad ass game, regardless if you're 6 or 16 or 60. I mean, a game doesn't have to be a sports game or something violent to be "for adults."
I couldn't give a rat's ass about gran turismo or the newest rpg. my roomate has a GC and I've not been left wanting... other than knights of the old republic...
Dreamcast is a 4th generation, though an early one, rather like the PS2. The Sega Saturn should go in the #3 space.
Does the Xbox have a video in port? Or are you recording on one machine and watching on the Xbox? Seems a bit much...
Umm... The comparisons had a lot more to do than hello world or boot times. Perhaps you missed the other sections of the article?
Qtopia has wasted years rewriting the low-level graphics stuff but doing no better than Palm or PPC on apps.
/dev/fb, SDL, and Qtopia, though if I were creating a standalone system I would just use the framebuffer display mode for Squeak and Dynapad. It works quite well, and for one window, X11 is overkill.
And not just no better, but quite a bit worse. Heck, I have found better and more available Linux/Unix adaptations for WinCE than for the Zaurus. It is easier to simply recompile a Linux app for the Zaurus, but a lot of those apps aren't usable on a PDA.
The right thing to do would be to develop an updated Newton-like environment (dynamic language, persistent database, XML data interchange, etc.) and not waste time with reinventing the low-level infrastructure
Huh! Are you my secret double or something?
That is the kind of solution I have favored, and the one I have been working on. The dynamic language is Squeak Smalltalk. THe persistent database is Magma, and object database system for Squeak. Some XML interchange- through XML-RPC and SOAP- but it isn't used as the storage format.
The system I am working on it is called Dynapad. You can see some new screenshots here. The wiki hasn't been touched in a long time, and it was rolled back (think their server had an issue, had to restore from a backup) and I have not had the time to redo it all. Mind you, work continues and I have done a lot since I have made a release. I will be putting out a new release within a week, it is long overdue.
Linux and X11 are fine for modern handhelds--they need decent, modern apps.
Indeed. I generally advocate for using a Linux kernel as what is underneath; Squeak itself can run as an OS, but with so many drivers and other perks of using an establish kernel, I can't see why not to use it. Dynapad can run on Linux under X11, DirectFB,
And that's a real opportunity, because both Microsoft and Palm are sitting on their hands.
Again, you hit the nail on the head. Someting I have been saying for years. PDAs are a chance for us to start over again, and this time do it right. On Windows CE, the API is pretty compatible with regular Win32, but even so, it doesn't run regular Windows apps, so backwards compatibility isn't as compelling in that sense. PalmOS doesn't have the problem of backwards compatibility. They both had the chance to do it right, but they didn't. They didn't do it horribly, but still.
With the Linux/Qtopia situation, it is even worse. The community, as well companies like TrollTech and Sharp have done so little in this area. Even more so than MS and Palm, they had the chance to take that potential, the potential of creating a truly great, innovative (in the truest sense of the word) and forward look system. But they didn't. They took the easy way out. As a result, the situation is pretty crappy, and light-years from exceptional.
Don't forget- somewhere in the PalmOS 4.x series, Sony added a super primitive form of multitasking. Basically, all it did was allow one background thread which recieved only a tiny chunk of the machine's resources. All the thread could do is pipe data to the mp3 decoder chip on the lil guy's motherboard. that way, you could listen to mp3s *and* be in the addressbook at the same time! What an invention!
Hmpf! "PDAs don't need multitasking" they say! Ha! The PDA may not care, but I do! If I am going to spend anything more than $60 on something calling itself a PDA, it better damn well multitask, at least in a limited- but generally useful- fashion.
Similar to Sony's hack, PalmOS 5.2 has some very, very primitive two thread "multitasking," though in 5.2, the background thread is allowed to actually decode the mp3s and pipe it to the speaker rather than just to the decoder chip. Ooohhh, impressive!
Newton had something that might be called a "real PDA OS". The Sharp Zaurus has a "real OS that works well for a PDA".
:(
Ha! It is about time someone else said that- so I didn't have to. I often bring up the fact that I want my PDA to have something resembling a "real OS," or at least, provide multitasking and some other so-called "perks" that I expect in an OS, be it on a computer that fits on my desk or in my pocket.
PalmOS users often say- why would you need a PDA to have multitasking? A PDA isn't meant to multitask. But that certainly isn't true. The first PDA, the device for which the term was invented- the Apple Newton- had most of the features of a "real OS," as well as a number of advanced features that a lot of so-called modern OSes running on desktops didn't have. In a lot of ways, even a 10 year old Newton outclasses most of the PalmOS units in circulation.
What Zodiac should have done is put a real kernel and OS on the Zodiac and run PalmOS as a guest operating system under that.
PalmOS 6 is the answer, at least, the answer most PalmOS users and licensees are looking at. Hopefully it'll be a good answer, but I have some reservations. For one, it it seems a bit silly that in apps for PalmOS 6, an OS that only can run on ARM CPUs (no m68ks!), the developer has to go out of her way to develop special code for native ARM, the default being to compile everything to m68k. And then they emulate the m68k CPU. Except, to my knowledge, PalmSource hasn't discussed what they're going to do about this in POS 6.x, 7 and beyond. Are they going to take a path like Apple's? Are they going to cripple users with performance, emulating 68k code for the next couple major versions, or will POS 6.x be the transition series, with POS 7 and beyond being native-ARM by default, without developers having to go out of their way to write ARMlets for only some selected functions?
The unfortunate thing about having the Zodiac run a "real kernel and OS" is that there really doesn't seem to be a good option for it. Sharp has proved that Linux+Qtopia really isn't ready for the privilege of running on a device in this class and category. Hell, there isn't even a way to use the Zaurus C7x0's Imageon 100 gfx chip, and I can't imagine the situation would be much different with the Imageon 4200 on the Zodiac.
With Linux, there is too much of a temptation for the company using it to just approach it like they're getting a deal, saving $15 per unit for the WinCE.NET 4.2 licensing fee. Linux could be very worthwhile if some company(ies) was willing to put a lot of time and money into Linux on the PDA, advancing the state of the art in a lot of areas. Sharp sure as hell isn't doing it.
The only option I can see is Windows CE. Now don't get me wrong, I like Windows CE; if only because it is the least sucky choice to be made for me as a PDA user. I'd rather be using NewtonOS, but that isn't much of an option for me anymore.