Yes, I eventually discovered how to do this with NetInfo. It wasn't too easy to find good documentation, and there were some unpleasant complexities. For example, you can't use vfstype=afp and name=afp:///blah (even though you CAN use vfstype=nfs and name=host:/path for NFS mounts), you have to use vfstype=url and opts=url==afp://blah . This is despite the fact that:
mount -t afp afp://host/path/mountpoint
works, but
mount -t url -o url==afp://host/path/mountpoint
fails, claiming there is no mount_url command (and well, there isn't). Just to make things even more fun, a static mount (ie in/Network/<sharename> and without the 'net' option) isn't actually static, it's still mounted on first access, and this breaks some applications that seem to use access mechanisms that don't trigger the automount. The mounts also appear in a different place (/Network/<sharename> or for dynamic mounts/Network/Servers/Hostname/Sharename) than they would if the user had connected to the mount manually (/Volumes for a Go->Connect to Server mount, somewhere else in/Network otherwise).
umount also deletes the mount point, but mount does not create it. fstab isn't used as it is on UNIX, but is instead merged into NetInfo on boot, where it's interpreted with entirely different semantics to what the fstab file has. Fstab is a table of static file system mounts, not an automount map. That's what automount maps are for. The `umount' and `fstab' man pages don't document these quirks, but instead refer to the conventional BSD behaviour.
I don't think there's any excuse for this sort of behaviour. If the documentation was accurate, and NetInfo / lookupd / autodiskmount / whatever did less behind-your-back magic, that'd be OK... but neither of those seem to be true.
It's all fine if you ignore the not-really-UNIX-like underlayer - there's nothing inherently wrong with most of this behaviour. However, it's incorrectly documented and looks just UNIX-like enough on the surface to suck you in before it beats you up.
I still haven't found out how to get Mac OS X to do a _genuinely_ static mount (connect at log-in time or boot-time) of a network volume without hacking the startup scripts. Even that has problems, apparently due to some issue with Carbon and Cocoa apps needing volumes to be "registered" with the "VolInfo database".
On Mac OS 9, I can just tick one box ("connect at next boot") and it just works. Well, at least 80% of the time;-)
Frameworks:
I didn't want to write a massive speil on this. I don't think there's anything wrong with framworks, and think they solve some significant problems, especially for an OS with a drag-and-drop software installation interface as opposed to an intergrated package-manager based one. My issue is solely with the way they completely ignored the way the linker command syntax works and made up their own that breaks piles of build tools. It's a minor issue, but it's really annoying, and it's a strong point in terms of why you need to be able to test software on Mac OS X if you want to have any hope of being able to build software that'll compile there.
GUI apps from a terminal:
Yes, it is possible to launch a GUI app from the terminal. I know the real binary is inside the.app bundle - I *write* apps for Mac OS X. Hence most of the issues I outlined - I'd hardly be bitching about linker options otherwise. The problme is that unless an application is started by Launch Services (not sure that's the right name), some things are not properly set up. This results in many apps not getting their own global menu bar but instead interfering with the menu bar of Terminal.app, not getting their own dock icon, etc. The problem is confined to "real" Mac gui apps (Cocoa / Carbon) and Carbon/POSIX hybrids that use Aqua; it doesn't affect X11/POSIX apps. This w
I've looked into it, and it's interesting, but not really attractive.
(a) I have to go and buy Mac OS X. Unless I'm selling significant quantities of software for Mac OS X, or have a significant base of users on it, that's not an attractive prospect. Especially having to keep the bloody thing up to date. Since most of the work I do that gets used on Mac OS X is open source that brings in exactly $0, that's not attractive.
(b) PearPC is sloooooooooooooooooow. The main app I work on takes about 15 minutes to clean rebuild on my Athlon 64 3200+ with gcc4. On a 1GHz eMac (Mac OS X 10.3), it takes over an hour and a half. This is a screaming nightmare when I have to change a major header file. PearPC is some 50 times slower than native execution, suggesting that I could expect build times vastly longer than even on the eMac at work that I currently test on over ssh. That's not at all attractive, in fact it's almost unusable. Imagine building Qt on PearPC.... *shudders*.
PearPC might be remotely useful with a cross-compiation environment. I'm not aware of anything that useful being possible with Mac OS X, so even that clumsy and frustrating option is probably out.
Now that Apple is moving to x86, I think there's a very strong argument in favour of them providing cheap, easy, and fast access to Mac OS X evironments for developers. It wouldn't take much to make a "Developer edition" unattractive to your average user, but still extremely useful for developers who target Mac OS X as a secondary platform. Virtualization would be a great starting point for the "cheap" and "easy" points, and isn't too bad at all when it comes to "fast".
What I really, really want is a developer version of Mac OS X / x86 that can run under Xen (or VMWare). It doesn't need to include drivers for real hardware, the iApps, etc, just the main OS and the developer tools.
Why? Because it means I can test my application on a "Mac" without having to fork out for hardware I don't want. This benefits me (save some cash / easier to test the app on another platform) and Apple (more apps for Mac OS X).
If their "virtual Mac OS X for Developers" is sufficiently cut down, it'd probably be a real PITA to install on real hardware, largely eliminating fears they might have about undercutting their hardware sales. Sure, you could build a thin Xen system just to load the Mac OS X image, but I really doubt this would be attractive to many people. Certainly not to your average Mac user.
Currently, Mac OS X is just UNIX-like enough to lull you into a brief false sense of security before brutally stabbing you in the back and raping your corpse. Any developer of cross-platform apps or UNIX apps who needs more than core POSIX facilities MUST actively test on Mac OS X to have a hope of things actually working when it comes to someone trying to use the application. This is doubly true of GUI apps using portable toolkits - Mac OS X has quite a few special traps for GUI developers who work on Linux and target Mac OS X.
Don't believe me about Mac OS X's very much un-UNIX-like true heart? Try to add a static network mount. Just drop it in fstab, and it'll all be there, right? . Sorry yet?. Now look at the syntax in `ld' for linking "framework" libraries, and hell, the fact that "framework" libraries exist. If you haven't worked on build systems, you won't understand the horror of that one. If you haven't given up yet, try starting a GUI app from the console. Tip: You have to use the special "open" command, just executing it isn't enough. It goes on, and on. None of these things are all that bad (well, except for the retard who chose to ignore all compatibility and use "-framework name" instead of "-framework,name" in the linker options) but they're all very frustrating for someone developing for UNIX. They're also good reasons to inform any Mac user who claims that "Mac OS X is just UNIX on the inside" just how wrong they are... with a spiked hammer. All these sorts of issues make it crucial to test on Mac OS X... but yet, Mac OS X is one of the harder common platforms to test on due to the need for special hardware and the lack of developer / "lite" OS versions.
A virtualisation-friendly version of Mac OS X for developers would help address this, without cutting into Apple's pricey OS and hardware sales. Anybody able to suggest a downside?
Gah, if recommending a text based browser, please at least recommend a decentone! Lynx has aged rather poorly IMO, and is massively surpassed by elinks and especially w3m. In fact, w3m is good enough that sometimes I can't be bothered starting up X on my (very) aged laptop - though the lack of Unicode support in the Linux virtual console layer is annoying.
What the channel is (a eg on freenode -dev channel isn't the best place to ask newbie questions, #gimp isn't a good place to ask any questions, #python tends to be very forgiving of newbies, etc) and where it is
The people on that channel (duh!)
To an extent the topic you're interested in, since that seems to affect (1) and (2) rather strongly
Your attitude and approach when asking for help
How much effort you've put into finding out for yourself first
How you respond if directed to a FAQ (tip: don't say "oh, I don't want to read that, can you explain it to me now?")
In general, I find there are unhelpful places full of jerks, and some great channels full of people who're great to talk to and work with. Most channels are inbetween, and at least on freenode (the main IRC server I use) tend toward "great and helpful".
Well, thanks to proftpd I don't have to worry much about the server security issue for FTP. I don't like the fact that it's in the clear and that few clients support digest authentication, SSL wrappers, or STARTLS, but since this would be a semi-public service it'd be OK in this one case.
The problem is that experience has shown me that FTP is, in fact, not idiot proof. Even with shell integration in WinXP and Mac OS X, and a document with lots of detailed screenshots, clients just *can't* *do* *it* and will fall back to emailing you the damn ad.
Frankly, I don't know what _would_ solve the problem, given the number of users who seem to be incapable of doing more than sending an email.
I guess a third thing changed in the interim - a good five years of programming experience that I didn't have when forced to use 1.2 . I may be a crap programmer now, but man I was awful then. I should also note that I was forced to use 1.2/for applets/ which might be no small part of my remembered loathing.
It's a bit sad, actually, given that the languages I'd been using prior to that had sort comparitors, lambda functions, etc so I should really have found the related features in Java. *curses*.
Nonetheless, Generics are also a big deal for me since I do much of my work in C++ now. No templates? *sob*. Problem solved by Java 1.5 (at least well enough for most template uses that aren't arguably abuse of the template system for complile-time metaprogramming).
Java 1.5 introduced the two things that make me willing to consider Java as a practical language for real work (as opposed to a "safe to let untrained programmers run rampant, too bad about the 10000k LoC required to do anything" language). Those two things are collections and generics.
I was forced to use Java 1.2 some time ago, and found it a horrific experience with my background in dynamic languages. Since then, I've learned C++ and got used to the pluses and minuses of static languages (both in the sense of "compiled" and in the sense of "statically typed"). Java also largely ceased to suck, so having to work on it again and finding that sort code that would've been hundreds and hundreds of repetitive lines can now be expressed using a short set of comparitors and a collections-based sort was... refreshing.
After Java 1.5, I can understand why they'd want to let things settle down for a while. It seems to me that they finally got all the really important stuff into the language.
Whether or not you'd like to use Oracle yourself, this is good news for software developers. It means they can deploy and test against a running version of Oracle with no need to worry about "developer program" memberships, trials that expire, and similar crud.
This'll be very helpful for me in ensuring that my code is portable across databases (at least PostgreSQL and Oracle).
It certainly has some accessibility support via UNO and ATK. How much or how well it works I really don't know.
When it comes to accessibility, many programmers are unaware of accessibility requirements, and some don't care. This sounds heartless, but is somewhat understandable from the "scratching an itch" PoV. Accessibility support is hard (especially since toolkits generally provide miserable support), and moreover is often considered "uninteresting". Perhaps most importantly, it's very hard to know where to even start, and to understand what's really needed.
Accessibility is one of the biggest areas in which corporate involvement is beneficial to open source projects. While most companies couldn't care less about accessibility, they're _required_ to support it by regulations. If they want to be able to make money off the software, they need to ensure it satisfies those guidelines.
Sun has been doing a very good job of enhancing accessibility in GNOME (http://www.sun.com/software/star/gnome/accessibil ity/architecture.xml). Perhaps most interestingly, now that they've helped get things going and show how it can be done, the wider community seems to be taking an interest in accessibility issues and in tools like ATK.
I'd actually be interested to know what the accessibility support in OO.o is like. I'd be surprised if it wasn't improving in a hurry, no matter what its current state.
Lawyers. Giant teeming armies of lawyers. It sounds like the profession has to a fair extent moved to Word, but it took a while, they held on for a long time, they have GIGANTIC archives of Wordperfect docs, and they still use it a lot.
The format its self is pretty compatible and hasn't changed that much since Office '97, and content seems to come across very reliability. The issue seems to be with formatting, especially complex formatting done by people who abuse Word to try to turn it into a page layout / DTP tool. These documents don't tend to make the transition from a newer version back to an older one at *all* well unless the user of the newer version is working in a mode that only gives them features from the older version, in which case it seems to be mostly fine.
Opening files from older versions in the newer versions seems very solid.
As for default printer, page size, and margins - "ARRRRGGGHHHH!". Word almost always defaults to US Letter no matter where the user is, and most users will never change this. They print to an inkjet that doesn't care; the most that'll happen is slightly off margins. Consequently, if you've got your system correctly set up and you use a network laser printer that _does_ care about paper sizes, working with 90% of Word users is a screaming nightmare of exploding documents and printer errors. Combine this with working for a newspaper where lots of clients seem to think that Word is a great tool for doing an ad layout to be printed in the paper, and you have a recipe for pure hell.
To say I was happy when I heard about Office 12's native PDF support (even though for Word it'll be barely adequate for our needs, being more focused on the sorts of things word SHOULD be used for) would be the understatement of the century.
The description of the plugin suggests that it should be possible to port it to older Word versions too. Remember that Microsoft are retrofitting Word 12 XML support into older versions of Word (I'm not so sure about other apps, but I *think* the same is true for Excel and Powerpoint).
Given that, you just use the XSL to produce an Office 12 XML doc, then open that with the existing support, much like in Office 12. I imagine you'd probably get somewhat inferior results, but then one expects that when using an older version.
In the case of XML 1.0, any encoded text stream (usually Unicode, please oh god not ASCII) . I'm pleased to see that XML 1.1 tightens this up a little. They still leave a gaping hole for confusion between UCS-2 and UTF-16 (and beween UCS-4 and UTF-32) by defining "unicode encoding form" as "encoded in UTF-8, UTF-16 or UTF-32" but "legacy encoding" as "any character encoding not based on Unicode." Still, it's better than "god knows what encoding this document is in, it's missing a I regularly have to deal with software that assumes that input is in whatever encoding the authors happen to think is "universal" (utf-8, ucs-2, utf-16, ucs-4, 7-bit ASCII, ISO-8859-[1-15], cp-blah, and so on). It's horrific. Thankfully it's less commonplace with XML, which can be reasonably expected to be utf-8 or UCS-2 (but sometimes utf-16), but enough apps just write out a document with the current locale's encoding to be problematic. Some toolkits and libraries even encourage it with DOMs that handle text encoding issues inconsitently or ignore them, then make it worse by not writing out a <?xml processing directive .
I've already bought the nice heavy wooden bat. I'll be painting "text encodings" and "clue" on it in the coming holidays, and I'm still very tempted to add some nails. I'm in Perth, Western Australia, so I don't meet all that many other OSS developers, but I'll be bringing it when I do;-)
This little rant isn't aimed at you, by the way - it's more in agreement with you really. It's very much inspired by the parent poster, though it's not their fault (if they're not programming they don't need to know or care, and even if they do they were probably just being sloppy. It's not code, after all.).
Things like Exchange are great/within/ a company. Well, except for the server admin. They suck bigtime outside a company and between companies.
That's a large part of what these sorts of people are on about - working better within _and_ between companies - though I really don't know if they have anything interesting beyond hot air to offer. Anything that gives the customers at work a moron-proof interface to send us documents that DOESN'T involve email gets my vote.
Well, it's very expensive for people who're not in a hurry.
If you need a job done *now* and don't have time to build the cluster, I can see how it'd be attractive. Especially if it scaled really well, so you could spread it out over 2000 machines and finish in a day, instead of 100 machines for, say, two weeks.
I personally wonder if Sun might've got more business if they scaled the prices, so putting jobs on a few machines was way cheaper than putting them on a lot. Maybe then they'd have got people trying it out. Right now, it looks like to be worth it you've got to be in a serious hurry and/or unprepared, and willing to bet on a service you haven't used before. hmm.
Another barrier might be comms. You still have to get the data to the "grid" and get the results back. If we're talking terabytes - which isn't unlikely when talking about buying tens of thousands of CPU hours - then that's a big whack of data. Combine that with a customer who's in a hurry and doesn't already have their own HPC infrastructure...
Yep... but for all we know they did have customers lined up as it was being built. It wouldn't be the first time that a customer goes on and on and on about how great something will be and how much they're looking forward to it, then when it comes time to hand over the money they "reevaluate their priorities".
Technology companies, especially those customising software for a client, know what this is like all too well.
The Toshiba Libretto is probably what you're after then. They're *tiny*, and nice little laptops. Ok, so they're getting toward palmtops, but whatever.
I'm personally using a Toshiba Portege at the moment, and I'm very happy with the form factor. It has a 10" display that alas only does 800x600, but then it's about seven years old so it's hard to complain. They're also obviously well built, since this one has been through three war zones with a war correspondant.
I'm seriously eyeing the new model Portege (which alas has a crap trackpad and worse button positioning, and only a 1024x768 display, but is otherwise utterly droolworthy. In particular, it weighs almost nothing) or a Libretto. The new model libretto should be out soon, and I'll decide which to bankrupt myself on then.
I've been wondering about the possibility of something like this for some time. While I'm sure it has its fair share of downsides, it looks pretty darn good right now.
The *nix shell is wonderfully powerful, but can be highly inconsistent, is badly integrated ( sed, sh, awk, various network query tools, etc ), and falls down when manipulating more complex data. "scripting languages" are often clumsy at "shell" jobs, by contrast, and combining the two is often not very fun. I'd go insane without bash and Python, but I'm very near to going insane *with* bash as well;-) .
It's ten times worse on win32, where all the win32 admin automation options are crapware (cmd.exe), overly complex and clunky (WSH, VBScript), or difficult to integrate well into the OS (Python + pywin32, cygwin). IronPython looked really promising, and this looks more so, though I couldn't agree more with the criticisms leveled by the article author in the closing comments.
Seeing something like this that addresses those issues looks really exciting. The extended VFS namespace in the shell is particularly striking, especially when combined with one of MS's real strengths - network integration and AD. Too bad it'll be win32 only, because it looks like MS have finally "got it". They've gone for "everything is an object" not "everything is a file," (and similarly for object-streams not text-streams) but that's more appropriate for modern systems IMO.
Personally, I suspect that if this works out it'll massively increase the viability of win32 servers, and should really help bring down their admin time requirements. If MS are smart enough to ship a well integrated ssh daemon in the OS with msh hooked up to it, if they let you hook msh to a serial console, and if they let you boot into single-user msh-only mode, I might be seriously tempted by a win32 server for a few of our applications. The extent to which the miserable state of admin automation on win32 has kept me away from the platform is remarkable.
Actually, I think you'll find that it's business that moves really slowly. There are a *lot* of legacy systems out there that must be adjusted to the new rules, plus businesses need to work out what operational changes are required, how this will affect their dealings with other companies, etc. While the same is true of government, I suspect business will be the critical factor here since this decision is economically driven in the first place.
The legacy systems issue is especially crucial. I should know, since I'm the poor bastard in charge of one in Western Australia. We recently rejected adopting daylight savings (I've lived with and without; I don't care either way), and the two main negative argument was cost and disruption to business.
Of course, other negative arguments included "we'll have to get up earlier" (farmers) and "the curtains will fade faster." I kid you not. Yep, we're going to use scary weird magic to just/add/ an hour of daylight, that's it...
For simple cases that's true. If you're doing more complex, dynamic queries that's not really accurate. In particular, conditionally specifying clauses for WHERE and HAVING, and additional fields for ORDER BY, is annoying.
I've used languages with built-in database integration. In particular I did a bit with Progress 4GL. Progress isn't magic by any stretch (and it's tied to a database that makes MySQL 3 look advanced), but in my experience it did significantly reduce the frequency with which I had to start fiddling with query strings. Too bad it was such a dog in every other way.
These days I suspect many of the things I've been doing by fiddling with query strings may be better done with the application of a few stored procedures, possibly procedural stored procedures. There must be some better way.
There's one issue with database portability, and that's that each database uses different languages for stored procedures. This is getting better in some areas, and some DBs now have a basic procedural language that's mostly compatible, but it's not really good from a DB portability point of view.
Of course, for the plain SQL procedures that many or most of your stored procedures will be that's no problem at all. Porting your procedural stored procs isn't going to be too bad so long as they're all well documented and isolated neatly.
Additionally, many DBs let you use your preferred language for stored procedures - for example, Java or Python . Sometimes this can be a very handy thing, though of course abuse of it is hideous.
I tend to agree regarding doing data operations in the app. The more SQL and good database use I learn, the simpler the code that's responsible for fetching and storing data gets as more and more of it moves into the database its self.
SQL its self isn't the problem. SQL in apps, however:
- is an absolute PITA to assemble dynamically, involving lots of icky string mangling; - is often rather ugly; and - is not trivial to do safely - it's way too easy to expose SQL injection holes.
The point is that the patents are used as ammunition to force other vendors into cross licensing their patents. It all looks like an expensive farce... until you realise that small, up-and-coming potential competitors have no patents to use in cross licensing deals.
Consequently, software patents seem to permit the creation of a "big boys club" that shuts out smaller competitors. The word "cartel" doesn't currently apply to the large commerical software industry, but I wonder how much longer that'll be true...
Slashdot Mirror
Static mounts:
/mountpoint
/mountpoint
/Network/<sharename> and without the 'net' option) isn't actually static, it's still mounted on first access, and this breaks some applications that seem to use access mechanisms that don't trigger the automount. The mounts also appear in a different place (/Network/<sharename> or for dynamic mounts /Network/Servers/Hostname/Sharename) than they would if the user had connected to the mount manually (/Volumes for a Go->Connect to Server mount, somewhere else in /Network otherwise).
... but neither of those seem to be true.
;-)
.app bundle - I *write* apps for Mac OS X. Hence most of the issues I outlined - I'd hardly be bitching about linker options otherwise. The problme is that unless an application is started by Launch Services (not sure that's the right name), some things are not properly set up. This results in many apps not getting their own global menu bar but instead interfering with the menu bar of Terminal.app, not getting their own dock icon, etc. The problem is confined to "real" Mac gui apps (Cocoa / Carbon) and Carbon/POSIX hybrids that use Aqua; it doesn't affect X11/POSIX apps. This w
Yes, I eventually discovered how to do this with NetInfo. It wasn't too easy to find good documentation, and there were some unpleasant complexities. For example, you can't use vfstype=afp and name=afp:///blah (even though you CAN use vfstype=nfs and name=host:/path for NFS mounts), you have to use vfstype=url and opts=url==afp://blah . This is despite the fact that:
mount -t afp afp://host/path
works, but
mount -t url -o url==afp://host/path
fails, claiming there is no mount_url command (and well, there isn't). Just to make things even more fun, a static mount (ie in
umount also deletes the mount point, but mount does not create it. fstab isn't used as it is on UNIX, but is instead merged into NetInfo on boot, where it's interpreted with entirely different semantics to what the fstab file has. Fstab is a table of static file system mounts, not an automount map. That's what automount maps are for. The `umount' and `fstab' man pages don't document these quirks, but instead refer to the conventional BSD behaviour.
I don't think there's any excuse for this sort of behaviour. If the documentation was accurate, and NetInfo / lookupd / autodiskmount / whatever did less behind-your-back magic, that'd be OK
It's all fine if you ignore the not-really-UNIX-like underlayer - there's nothing inherently wrong with most of this behaviour. However, it's incorrectly documented and looks just UNIX-like enough on the surface to suck you in before it beats you up.
I still haven't found out how to get Mac OS X to do a _genuinely_ static mount (connect at log-in time or boot-time) of a network volume without hacking the startup scripts. Even that has problems, apparently due to some issue with Carbon and Cocoa apps needing volumes to be "registered" with the "VolInfo database".
On Mac OS 9, I can just tick one box ("connect at next boot") and it just works. Well, at least 80% of the time
Frameworks:
I didn't want to write a massive speil on this. I don't think there's anything wrong with framworks, and think they solve some significant problems, especially for an OS with a drag-and-drop software installation interface as opposed to an intergrated package-manager based one. My issue is solely with the way they completely ignored the way the linker command syntax works and made up their own that breaks piles of build tools. It's a minor issue, but it's really annoying, and it's a strong point in terms of why you need to be able to test software on Mac OS X if you want to have any hope of being able to build software that'll compile there.
GUI apps from a terminal:
Yes, it is possible to launch a GUI app from the terminal. I know the real binary is inside the
I've looked into it, and it's interesting, but not really attractive.
.... *shudders*.
(a) I have to go and buy Mac OS X. Unless I'm selling significant quantities of software for Mac OS X, or have a significant base of users on it, that's not an attractive prospect. Especially having to keep the bloody thing up to date. Since most of the work I do that gets used on Mac OS X is open source that brings in exactly $0, that's not attractive.
(b) PearPC is sloooooooooooooooooow. The main app I work on takes about 15 minutes to clean rebuild on my Athlon 64 3200+ with gcc4. On a 1GHz eMac (Mac OS X 10.3), it takes over an hour and a half. This is a screaming nightmare when I have to change a major header file. PearPC is some 50 times slower than native execution, suggesting that I could expect build times vastly longer than even on the eMac at work that I currently test on over ssh. That's not at all attractive, in fact it's almost unusable. Imagine building Qt on PearPC
PearPC might be remotely useful with a cross-compiation environment. I'm not aware of anything that useful being possible with Mac OS X, so even that clumsy and frustrating option is probably out.
Now that Apple is moving to x86, I think there's a very strong argument in favour of them providing cheap, easy, and fast access to Mac OS X evironments for developers. It wouldn't take much to make a "Developer edition" unattractive to your average user, but still extremely useful for developers who target Mac OS X as a secondary platform. Virtualization would be a great starting point for the "cheap" and "easy" points, and isn't too bad at all when it comes to "fast".
What I really, really want is a developer version of Mac OS X / x86 that can run under Xen (or VMWare). It doesn't need to include drivers for real hardware, the iApps, etc, just the main OS and the developer tools.
... with a spiked hammer. All these sorts of issues make it crucial to test on Mac OS X ... but yet, Mac OS X is one of the harder common platforms to test on due to the need for special hardware and the lack of developer / "lite" OS versions.
Why? Because it means I can test my application on a "Mac" without having to fork out for hardware I don't want. This benefits me (save some cash / easier to test the app on another platform) and Apple (more apps for Mac OS X).
If their "virtual Mac OS X for Developers" is sufficiently cut down, it'd probably be a real PITA to install on real hardware, largely eliminating fears they might have about undercutting their hardware sales. Sure, you could build a thin Xen system just to load the Mac OS X image, but I really doubt this would be attractive to many people. Certainly not to your average Mac user.
Currently, Mac OS X is just UNIX-like enough to lull you into a brief false sense of security before brutally stabbing you in the back and raping your corpse. Any developer of cross-platform apps or UNIX apps who needs more than core POSIX facilities MUST actively test on Mac OS X to have a hope of things actually working when it comes to someone trying to use the application. This is doubly true of GUI apps using portable toolkits - Mac OS X has quite a few special traps for GUI developers who work on Linux and target Mac OS X.
Don't believe me about Mac OS X's very much un-UNIX-like true heart? Try to add a static network mount. Just drop it in fstab, and it'll all be there, right? . Sorry yet?. Now look at the syntax in `ld' for linking "framework" libraries, and hell, the fact that "framework" libraries exist. If you haven't worked on build systems, you won't understand the horror of that one. If you haven't given up yet, try starting a GUI app from the console. Tip: You have to use the special "open" command, just executing it isn't enough. It goes on, and on. None of these things are all that bad (well, except for the retard who chose to ignore all compatibility and use "-framework name" instead of "-framework,name" in the linker options) but they're all very frustrating for someone developing for UNIX. They're also good reasons to inform any Mac user who claims that "Mac OS X is just UNIX on the inside" just how wrong they are
A virtualisation-friendly version of Mac OS X for developers would help address this, without cutting into Apple's pricey OS and hardware sales. Anybody able to suggest a downside?
Tried a user stylesheet? A style for the body tag might work. Something vaguely like this might be worth a go:
! body { width: 1200px ; }
(the ! means "Important, should override a style set on the page". Not sure that's the right syntax, though.)
Gah, if recommending a text based browser, please at least recommend a decent one! Lynx has aged rather poorly IMO, and is massively surpassed by elinks and especially w3m. In fact, w3m is good enough that sometimes I can't be bothered starting up X on my (very) aged laptop - though the lack of Unicode support in the Linux virtual console layer is annoying.
- What the channel is (a eg on freenode -dev channel isn't the best place to ask newbie questions, #gimp isn't a good place to ask any questions, #python tends to be very forgiving of newbies, etc) and where it is
- The people on that channel (duh!)
- To an extent the topic you're interested in, since that seems to affect (1) and (2) rather strongly
- Your attitude and approach when asking for help
- How much effort you've put into finding out for yourself first
- How you respond if directed to a FAQ (tip: don't say "oh, I don't want to read that, can you explain it to me now?")
In general, I find there are unhelpful places full of jerks, and some great channels full of people who're great to talk to and work with. Most channels are inbetween, and at least on freenode (the main IRC server I use) tend toward "great and helpful".Well, thanks to proftpd I don't have to worry much about the server security issue for FTP. I don't like the fact that it's in the clear and that few clients support digest authentication, SSL wrappers, or STARTLS, but since this would be a semi-public service it'd be OK in this one case.
The problem is that experience has shown me that FTP is, in fact, not idiot proof. Even with shell integration in WinXP and Mac OS X, and a document with lots of detailed screenshots, clients just *can't* *do* *it* and will fall back to emailing you the damn ad.
Frankly, I don't know what _would_ solve the problem, given the number of users who seem to be incapable of doing more than sending an email.
Whoops, you're quite right.
/for applets/ which might be no small part of my remembered loathing.
I guess a third thing changed in the interim - a good five years of programming experience that I didn't have when forced to use 1.2 . I may be a crap programmer now, but man I was awful then. I should also note that I was forced to use 1.2
It's a bit sad, actually, given that the languages I'd been using prior to that had sort comparitors, lambda functions, etc so I should really have found the related features in Java. *curses*.
Nonetheless, Generics are also a big deal for me since I do much of my work in C++ now. No templates? *sob*. Problem solved by Java 1.5 (at least well enough for most template uses that aren't arguably abuse of the template system for complile-time metaprogramming).
Java 1.5 introduced the two things that make me willing to consider Java as a practical language for real work (as opposed to a "safe to let untrained programmers run rampant, too bad about the 10000k LoC required to do anything" language). Those two things are collections and generics.
... refreshing.
I was forced to use Java 1.2 some time ago, and found it a horrific experience with my background in dynamic languages. Since then, I've learned C++ and got used to the pluses and minuses of static languages (both in the sense of "compiled" and in the sense of "statically typed"). Java also largely ceased to suck, so having to work on it again and finding that sort code that would've been hundreds and hundreds of repetitive lines can now be expressed using a short set of comparitors and a collections-based sort was
After Java 1.5, I can understand why they'd want to let things settle down for a while. It seems to me that they finally got all the really important stuff into the language.
Whether or not you'd like to use Oracle yourself, this is good news for software developers. It means they can deploy and test against a running version of Oracle with no need to worry about "developer program" memberships, trials that expire, and similar crud.
This'll be very helpful for me in ensuring that my code is portable across databases (at least PostgreSQL and Oracle).
It certainly has some accessibility support via UNO and ATK. How much or how well it works I really don't know.
l ity/architecture.xml). Perhaps most interestingly, now that they've helped get things going and show how it can be done, the wider community seems to be taking an interest in accessibility issues and in tools like ATK.
When it comes to accessibility, many programmers are unaware of accessibility requirements, and some don't care. This sounds heartless, but is somewhat understandable from the "scratching an itch" PoV. Accessibility support is hard (especially since toolkits generally provide miserable support), and moreover is often considered "uninteresting". Perhaps most importantly, it's very hard to know where to even start, and to understand what's really needed.
Accessibility is one of the biggest areas in which corporate involvement is beneficial to open source projects. While most companies couldn't care less about accessibility, they're _required_ to support it by regulations. If they want to be able to make money off the software, they need to ensure it satisfies those guidelines.
Sun has been doing a very good job of enhancing accessibility in GNOME (http://www.sun.com/software/star/gnome/accessibi
I'd actually be interested to know what the accessibility support in OO.o is like. I'd be surprised if it wasn't improving in a hurry, no matter what its current state.
"WordPerfect - is anybody using that anymore?"
Lawyers. Giant teeming armies of lawyers. It sounds like the profession has to a fair extent moved to Word, but it took a while, they held on for a long time, they have GIGANTIC archives of Wordperfect docs, and they still use it a lot.
The format its self is pretty compatible and hasn't changed that much since Office '97, and content seems to come across very reliability. The issue seems to be with formatting, especially complex formatting done by people who abuse Word to try to turn it into a page layout / DTP tool. These documents don't tend to make the transition from a newer version back to an older one at *all* well unless the user of the newer version is working in a mode that only gives them features from the older version, in which case it seems to be mostly fine.
Opening files from older versions in the newer versions seems very solid.
As for default printer, page size, and margins - "ARRRRGGGHHHH!". Word almost always defaults to US Letter no matter where the user is, and most users will never change this. They print to an inkjet that doesn't care; the most that'll happen is slightly off margins. Consequently, if you've got your system correctly set up and you use a network laser printer that _does_ care about paper sizes, working with 90% of Word users is a screaming nightmare of exploding documents and printer errors. Combine this with working for a newspaper where lots of clients seem to think that Word is a great tool for doing an ad layout to be printed in the paper, and you have a recipe for pure hell.
To say I was happy when I heard about Office 12's native PDF support (even though for Word it'll be barely adequate for our needs, being more focused on the sorts of things word SHOULD be used for) would be the understatement of the century.
The description of the plugin suggests that it should be possible to port it to older Word versions too. Remember that Microsoft are retrofitting Word 12 XML support into older versions of Word (I'm not so sure about other apps, but I *think* the same is true for Excel and Powerpoint).
Given that, you just use the XSL to produce an Office 12 XML doc, then open that with the existing support, much like in Office 12. I imagine you'd probably get somewhat inferior results, but then one expects that when using an older version.
In the case of XML 1.0, any encoded text stream (usually Unicode, please oh god not ASCII) . I'm pleased to see that XML 1.1 tightens this up a little. They still leave a gaping hole for confusion between UCS-2 and UTF-16 (and beween UCS-4 and UTF-32) by defining "unicode encoding form" as "encoded in UTF-8, UTF-16 or UTF-32" but "legacy encoding" as "any character encoding not based on Unicode." Still, it's better than "god knows what encoding this document is in, it's missing a
;-)
I regularly have to deal with software that assumes that input is in whatever encoding the authors happen to think is "universal" (utf-8, ucs-2, utf-16, ucs-4, 7-bit ASCII, ISO-8859-[1-15], cp-blah, and so on). It's horrific. Thankfully it's less commonplace with XML, which can be reasonably expected to be utf-8 or UCS-2 (but sometimes utf-16), but enough apps just write out a document with the current locale's encoding to be problematic. Some toolkits and libraries even encourage it with DOMs that handle text encoding issues inconsitently or ignore them, then make it worse by not writing out a <?xml processing directive .
I've already bought the nice heavy wooden bat. I'll be painting "text encodings" and "clue" on it in the coming holidays, and I'm still very tempted to add some nails. I'm in Perth, Western Australia, so I don't meet all that many other OSS developers, but I'll be bringing it when I do
This little rant isn't aimed at you, by the way - it's more in agreement with you really. It's very much inspired by the parent poster, though it's not their fault (if they're not programming they don't need to know or care, and even if they do they were probably just being sloppy. It's not code, after all.).
Things like Exchange are great /within/ a company. Well, except for the server admin. They suck bigtime outside a company and between companies.
That's a large part of what these sorts of people are on about - working better within _and_ between companies - though I really don't know if they have anything interesting beyond hot air to offer. Anything that gives the customers at work a moron-proof interface to send us documents that DOESN'T involve email gets my vote.
Well, it's very expensive for people who're not in a hurry.
If you need a job done *now* and don't have time to build the cluster, I can see how it'd be attractive. Especially if it scaled really well, so you could spread it out over 2000 machines and finish in a day, instead of 100 machines for, say, two weeks.
I personally wonder if Sun might've got more business if they scaled the prices, so putting jobs on a few machines was way cheaper than putting them on a lot. Maybe then they'd have got people trying it out. Right now, it looks like to be worth it you've got to be in a serious hurry and/or unprepared, and willing to bet on a service you haven't used before. hmm.
Another barrier might be comms. You still have to get the data to the "grid" and get the results back. If we're talking terabytes - which isn't unlikely when talking about buying tens of thousands of CPU hours - then that's a big whack of data. Combine that with a customer who's in a hurry and doesn't already have their own HPC infrastructure...
Yep... but for all we know they did have customers lined up as it was being built. It wouldn't be the first time that a customer goes on and on and on about how great something will be and how much they're looking forward to it, then when it comes time to hand over the money they "reevaluate their priorities".
Technology companies, especially those customising software for a client, know what this is like all too well.
The Toshiba Libretto is probably what you're after then. They're *tiny*, and nice little laptops. Ok, so they're getting toward palmtops, but whatever.
I'm personally using a Toshiba Portege at the moment, and I'm very happy with the form factor. It has a 10" display that alas only does 800x600, but then it's about seven years old so it's hard to complain. They're also obviously well built, since this one has been through three war zones with a war correspondant.
I'm seriously eyeing the new model Portege (which alas has a crap trackpad and worse button positioning, and only a 1024x768 display, but is otherwise utterly droolworthy. In particular, it weighs almost nothing) or a Libretto. The new model libretto should be out soon, and I'll decide which to bankrupt myself on then.
I've been wondering about the possibility of something like this for some time. While I'm sure it has its fair share of downsides, it looks pretty darn good right now.
;-) .
The *nix shell is wonderfully powerful, but can be highly inconsistent, is badly integrated ( sed, sh, awk, various network query tools, etc ), and falls down when manipulating more complex data. "scripting languages" are often clumsy at "shell" jobs, by contrast, and combining the two is often not very fun. I'd go insane without bash and Python, but I'm very near to going insane *with* bash as well
It's ten times worse on win32, where all the win32 admin automation options are crapware (cmd.exe), overly complex and clunky (WSH, VBScript), or difficult to integrate well into the OS (Python + pywin32, cygwin). IronPython looked really promising, and this looks more so, though I couldn't agree more with the criticisms leveled by the article author in the closing comments.
Seeing something like this that addresses those issues looks really exciting. The extended VFS namespace in the shell is particularly striking, especially when combined with one of MS's real strengths - network integration and AD. Too bad it'll be win32 only, because it looks like MS have finally "got it". They've gone for "everything is an object" not "everything is a file," (and similarly for object-streams not text-streams) but that's more appropriate for modern systems IMO.
Personally, I suspect that if this works out it'll massively increase the viability of win32 servers, and should really help bring down their admin time requirements. If MS are smart enough to ship a well integrated ssh daemon in the OS with msh hooked up to it, if they let you hook msh to a serial console, and if they let you boot into single-user msh-only mode, I might be seriously tempted by a win32 server for a few of our applications. The extent to which the miserable state of admin automation on win32 has kept me away from the platform is remarkable.
Good on MS.
Actually, I think you'll find that it's business that moves really slowly. There are a *lot* of legacy systems out there that must be adjusted to the new rules, plus businesses need to work out what operational changes are required, how this will affect their dealings with other companies, etc. While the same is true of government, I suspect business will be the critical factor here since this decision is economically driven in the first place.
/add/ an hour of daylight, that's it...
The legacy systems issue is especially crucial. I should know, since I'm the poor bastard in charge of one in Western Australia. We recently rejected adopting daylight savings (I've lived with and without; I don't care either way), and the two main negative argument was cost and disruption to business.
Of course, other negative arguments included "we'll have to get up earlier" (farmers) and "the curtains will fade faster." I kid you not. Yep, we're going to use scary weird magic to just
For simple cases that's true. If you're doing more complex, dynamic queries that's not really accurate. In particular, conditionally specifying clauses for WHERE and HAVING, and additional fields for ORDER BY, is annoying.
I've used languages with built-in database integration. In particular I did a bit with Progress 4GL. Progress isn't magic by any stretch (and it's tied to a database that makes MySQL 3 look advanced), but in my experience it did significantly reduce the frequency with which I had to start fiddling with query strings. Too bad it was such a dog in every other way.
These days I suspect many of the things I've been doing by fiddling with query strings may be better done with the application of a few stored procedures, possibly procedural stored procedures. There must be some better way.
There's one issue with database portability, and that's that each database uses different languages for stored procedures. This is getting better in some areas, and some DBs now have a basic procedural language that's mostly compatible, but it's not really good from a DB portability point of view.
Of course, for the plain SQL procedures that many or most of your stored procedures will be that's no problem at all. Porting your procedural stored procs isn't going to be too bad so long as they're all well documented and isolated neatly.
Additionally, many DBs let you use your preferred language for stored procedures - for example, Java or Python . Sometimes this can be a very handy thing, though of course abuse of it is hideous.
I tend to agree regarding doing data operations in the app. The more SQL and good database use I learn, the simpler the code that's responsible for fetching and storing data gets as more and more of it moves into the database its self.
SQL its self isn't the problem. SQL in apps, however:
- is an absolute PITA to assemble dynamically, involving lots of icky string mangling;
- is often rather ugly; and
- is not trivial to do safely - it's way too easy to expose SQL injection holes.
The point is that the patents are used as ammunition to force other vendors into cross licensing their patents. It all looks like an expensive farce ... until you realise that small, up-and-coming potential competitors have no patents to use in cross licensing deals.
Consequently, software patents seem to permit the creation of a "big boys club" that shuts out smaller competitors. The word "cartel" doesn't currently apply to the large commerical software industry, but I wonder how much longer that'll be true...