Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Mac OS X, XML, and Aqua

Posted by CmdrTaco on Wed Mar 01, 2000 08:58 AM
from the stuff-to-read dept.
Gr1nderX writes, "Ars just posted a large Mac OS X DP3 technical article that talks about the structure and functioning of OS X's (UNIX) filesystem, and how that impacts the Aqua GUI. IMHO, the most fascinating part of the article concerns the extensive use of XML that Apple makes in managing application resources, file meta-information, service configuration and startup options, etc. The XML parser that's built into the core OS basically gives you the ability to use either the GUI or a text editor to completely control and configure every aspect of the OS. " Lot of good stuff in this one: if only powerbooks weren't so expensive...
+ -
unknown
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • by Anonymous Coward
    Mozilla uses James Clark's expat parser [mozilla.org] -- Hervé - http://altern.org/mozillazine/
  • This is why you make everything that uses it that _needs_ to work link the libraries in statically. That way if some fsckwit removes /lib/*expat* you wouldn't be in too much trouble and would still be left with a semi-workable system. This is the same reason I use statically-linked binaries for the _most_ important things on my machines. (once bitten...) - A.P.
    --


    "One World, one Web, one Program" - Microsoft promotional ad

  • I think you have that backwards. I own a Mac and I never use MacOS. You couldn't pay me enough to run 1984's operating system. Apple's hardware is very good for the price--my PowerBook has every feature I need built in, a large bright screen, even SCSI, and very good battery life. Why would I want to run an operating system that still doesn't use protected memory?

    --
  • And the Powerbook has the Airport slot under the keyboard, and it supports an external monitor. And it has the same Rage128 chip set that the new iMac and iMac DVs have...and it ain't shabby playing Quake3 or UT on.

    Of course the Airport adds 100 bucks to the price, but the Lucent PCMCIA cards are...$140? Or was it $170?
  • The problem is that XML merely provides a data format. It does not inherently provide a robust way of rewriting files, which is what is truly important for a configuration system.

    I'd think it more valuable to, on a case-by-case basis, adopt libPropList. [rpmfind.net] That provides the benefit of a relatively generic format, but, more importantly, with the merit that it comes with library calls to modify data, and to do so in a safe way.

  • Who would this really help??

    1) Not new users trying to learn to edit config files by hand. With the current system, they have to learn the format and nuances of each config file. In an XML-based system, not only would they need to learn the DTD for each config file, but they'd need to learn XML before they could do anything at all. Don't know about the rest of you, but I'd rather edit a plain old text file than muck around with XML.

    2) Not new users interested in using a system administration tool. We already have several that work just fine w/o XML.

    3) Not exisiting users. They've already learned how to do it, why should they have to re-learn a new method that is of rather dubious benefit???

    I think XML is great and all for document storage, but let's be cautious about shoehorning it into other areas.
  • Bundles are something they have been needed for a long time from a user standpoint. New users almost always nuke a needed linked library or some file because they didn't recognize it and therefore didn't think it was important. I have missed the Extentions folder several times on my PB because of the trackpad and my big fingers. Windows and Linux devheads ought to take a que and try to incorpoarate a similar system into their apps. Windows 98 had CABs which were never much implimented by developers and therefore never seen by much of anyone. XML is another nice choice for congifuration, especially with the parser embedded in the core of the OS. Aqua on the otherhand bothers me, it seems like a nice idea and it is cute but is it going to get in the way of people like me who use professional apps like Photoshop? I don't want to fight with the UI when I want to apply a filter or scale something. I'd like OS X's stability and robustness but I really don't want a massive GUI hogging up my Powerbook's resources just to minimize a window. This was much longer but IE refreshed and nuked it.
  • Just an FYI.

    I am running MacOS X DP3 on my B&W G3/350 with 128MB of RAM and it runs "smoothly". I find it just as fast or faster than MacOS 9, for window drawing, updates, that sort of things. The only thing that is a little slower is launching apps and that is probably mostly due to debug code.

    As we've been discussing with the author of the article on MacOSX Talk... this is review of a "Developer Preview" a.k.a. pre-Beta. You can't expect much.

    Anyone remember how stable/fast W2K (then NT5) was when it was still in Alpha? I do. ;)
  • The main benefit to having everything in XML is that it gives you a standard means of modifying the config files. You could load up anything into, say, Conglomerate [conglomerate.org], and edit away. (Emacs/vi will work too, although XML is less plaintext-editor friendly). But more importantly, things like linuxconf and your typical next-gen admin tool will finally have a clean, standardized way of parsing and modifying those files, rather than the black magic being used at present. It's much easier to attain that you-can-use-a-text-editor-or-the-gui-tools-equally -well balance with XML, regardless of the number of particular DTD's involved.
  • I noticed a few comments from macOS users, but too many from clueless wintel slaves. Here's a little information for the ignorant (just as I am ignorant to the depths of being an admin for an winNT server) :

    Working on web and pre-press design
    projects I will run (remember this is a powerbook):
    Netscape Navigator (up to 10 or 12 windows open especially if I am using some online tutorials, or references)
    Netscape Communicator (checking email in real time from email server)
    BBEdit with numerous files open
    Adobe Photoshop/Illustrator/Pagemaker/Acrobat - drag and dropping between apps, and with probably up to 20 files open of various sizes depending on the project at hand.
    Three copies of Hotline1.2.3 connected to servers
    ICQ (when their damn server isnt down)
    NiftyTelnet 1.1 SSH r3
    and SoundJam MP for a little audio caffeine, sometimes streaming in off of a 10mb line into a OC3-T1.

    Now this all functions, not because its mac, but because I have a more than average RAM supply and an external monitor in the office. But the system including RAM and external monitor was about $3500.

    The system:
    400mhz G3 1 mb lvl2 cache (one cycle G3 != one cycle PIII, G3 is faster cycle/cycle)
    320 mb RAM
    MacOS9
    Internal ATA 6gig drive
    10/100 Base-T ethernet
    14.1 active matrix @ 1024x768
    External 21" monitor @ 1280x1024 75hz 24bit color

    This is a stock system from apple, no upgrades (except the RAM). Granted I have a great network connection to a linuxPPX server - so the small HD isnt a problem - Otherwise, I dont know what you would need more!

    So if the above isnt enough processing power for you, well then you are just way to bad-ass for these little mac toys. For a real computer call 1-800-g-a-t-e-w-a-y.

  • You sir are obviously clueless. MacOS currently is a tradeoff, as anyone will admit many aspects are dated. I still vastly prefer it to my linux box and windows box (yes, I am an avid unix user who owns and uses a mac) for desktop usage. The multitasking isn't great, but I'm not running a web server anyway, I'm pretty much doing a few things at a time.

    Second, if you feel there is only one app for OSX, you are further demonstrating your cluelessness. There are many great Cocoa apps out there, you have apps being updated for Carbon, and thanks to John Carmack, you have X windows with a BSD core. So let's count here. You can run classic MacOS apps, Carbonized apps, Cocoa/NeXT apps, and some X apps. That's a lack of software? yes, OSX is different, but if you look at Steve Jobs history, he likes to make surprises. There's no way in hell he's given the general public all the details 6 months before release. At least wait until it's released before you start calling it a failure... Of course, you just can't win with you folks, who will curse MacOS because it's to outdated, and then curse OSX because it's been updated and thus is different from the outdated one you hate...

    BTW, in your uninformative post, you forgot to bash the lack of a floppy drive. What a bad Mac basher you are!

  • 1) You are correct, I hate how I have to hit command-tab instead of alt-tab to switch between apps. It makes the whole mac useless because even though I can tab cycle through apps I can't do it with the same keys as windows! Man, that's so stupid!

    2) Linux users are way more zelous than mac users. While mac users fully understand the limitations of their OS, but still feel it's a worthwhile tradeoff, Linux users tend to go cry to mommy whenever anyone says anything might be wrong with linux (Mindcraft benchmarks come to mind...)

  • Yeah, the dock sucks and I would much prefer my standard apple menu. But I know jobs likes to make a splash, so I'm sure there will be many surprises by release time, I keep hoping at least... With all the negative feedback about the dock, I would hope they still have time to bring back the apple menu.

    As for Jobs being ahead of his time, I think he's a great marketer. NeXTStep was kickass but I don't attribute that to jobs. But, he has a great sense of what the people want. The iMac is really more revolutionary than most techy geeks understand because it represents a shift from a computer as a tool to a compuer as an applience. pretty radical stuff once you realize that average joe doesn't want something he can recompile a kernel on, he wants something like his VCR that just works. But I have some issue with jobs. If I ever met him, I would probably shake his hand and then kick him in the nads...

  • Speed? Foundation Kits? These are my issues. AWT sucks and doens't have most of the functionality needed for GUI apps. Swing is pretty, but it's slow any horribly designed. If you want proof of this, figure out the Swing text model, undo manager, and cut and paste model, then compare it to the Cocoa NSText and NSTextView classes :) Cocoa is so much more elegant and usable. Java using the Cocoa AppKit is fine, only it's much slower than Obj-C using the same frameworks (yes, I've done side by side comparisons).

    Now for non gui apps, Java is alright. Servlets are cool. Java is pretty usable in WebObjects. The only thing I've noticed though is that a Java WO app uses a lot more memory than the same thing in Obj-C which might be an issue depending on the application.

  • Somebody stop this guy...
  • And you (sir?) are obviously...14?

    No, I am only 3, but I am exceptionally brilliant.

    That's precisely what I claimed, nothing more, nothing less. It's DATED. If you like reading between the lines, extrapolate some real meaning.

    Sorry, I failed to realize that your obvious lack of knowledge was meant to say it was dated. Such as that the vast majority of apps live in me-only land, and that macs are a crashbox. I run 7-9 applications at a time, typically iCab, Netscape, Photoshop, Macromedia Fireworks, BBEdit, SSH, and while I work, my mp3 player plays music in the background without skipping. But I guess I'm just lucky I didn't get one of those non multitasking crashboxes, cuz then when I typed in BBEdit and edited an image in photoshop, my mp3 player would stop playing. I pity the people with such poor macs (probably SE30's running system 6.5).

    Huh? Far from it, I heard there were over twenty. And once they finish the Pops ports, they'll go quite well with the Cocoa ones

    Hi, I'm reality, have we met? I've only hear of this one Win32 app called SpaceCadet, there must not be any more apps I can run on Windows.

    Quite possibly because he has no clue? I guess you were still waiting for Rhapsody until recently. Take heart, X is definitely GOING to happen!

    Shit, you mean Rhapsody isn't coming out soon? Damn, where's my gun.

    Now when did I do that? To refresh your memory: except X is an admission of failure of sorts Of course I suppose my failure to master the english language at my tender age of 3 kept me from understanding that you meant "we'll have to wait and see what happens when it hits the market"

    That's what made me guess 14 or so. While your grasp of syntax and grammar is quite remarkable, your semantics are less so.

    Well, you are off, but I appreciate the comment. I will be sure to tell my pre-kindergarden tutor about this, she will be most proud of me. Now if I could only learn to read.


  • I fail to see how starting over indicates failure. All things grow old and you reach a point where it's doing a lot of things it was never intended to do. You can keep hacking away at the thing, but there comes a time when it's just better to start clean and get rid of all the junk that isn't needed any more. I think MS will be forced to do this soon, although I think they should have done it already. How long did it take them to get Win2k out? If they'd started clean from scratch they could have made a more efficient, more stable OS with probably half the amount of code.

    Anyway, MacOS reached a point where continuing on the current base just wasn't logical (who wants to write pascal anymore?). Starting over does not mean MacOS was a failure, it just means that the current base had reached the end of it's usefullness. So what did they do? They took something they had been used for a while and was proven (NeXTStep, you want to talk about stability, NeXT was a rock) and started from there. Much like MS took their proven and stable NT core and used it to build a consumer OS. Now of course NeXT and MacOS are a lot different than NT and Win9x, but with 6 months until release and the only thing we know about it is from a developer preview, it's hardly time to assume that apple will be alientating their user base. There are many things I see I don't like in DP3, if it sucks when it comes out, I'll go back to linuxppc. Anything but windows...

    By the way, I intend to take this "Comprehension 101" class when I make it to elementary school. I hope they offer it.
  • Of course having a separate DTD for each program is silly. But recognizing that a lot of configuration files actually look quite similar allows you to standardize on a particular DTD for a whole class of programs.

    All apple did was bring some uniformity in the mess of anarchistic shell scripts. Uniformity is good for two reasons: It makes things easier to understand and it makes things more general.

    Understandability is good because that lowers training cost and generality is good because that makes it possible to reuse (parsers, tools and even settings).

    Aside from uniformity they also applied separation of concern. They removed hardcoded interdependencies between shell scripts. Unlike uniformity this improves flexibility.

    All apple is doing here is apply good software engineering principles (uniform behavior, separation of concern). The unix community should be asshamed that they need apple to point that out. After all unix has been around for some time.
  • to quote the sun xml tutorial [sun.com]

    How Can You Use XML?
    There are several basic ways to make use of XML:
    • Traditional data processing, where XML encodes the data for a program to process
    • Document-driven programming, where XML documents are containers that build interfaces and applications from existing components
    • Archiving -- the foundation for document-driven programming, where the customized version of a component is saved (archived) so it can be used later
    • Binding, where the DTD or schema that defines an XML data structure is used to automatically generate a significant portion of the application that will eventually process that data
  • Don't rule out iBooks either. $1600 gets you a lot of machine.
    • 300MHz G3
    • 12.1" TFT (800x600) ATI Rage
    • 64MB/6GB/CD
    • 10/100enet,56kbit modem
    • USB
    • 6 hour batterlife.

    I wish the firewire hadn't been deleted, but I haven't needed it yet. The screen is a bit tight depending on what programs you run.
    Thats a real 6 hour battery life. I routinely go 6 hours doing program development.
    Definately get the $100 Airport. Nothing like sitting back in the comfy chair or out in the yard handling support calls.

  • After all, Xmas doesn't have support for the X Window System, either. I hear someone might be doing a port, but Tux is miffed that Santa hasn't relocated to the south pole to take advantage of the large number of linux-literate penguins there, and let's not even get started on what the BSD d[a]emon thinks.
  • >Of course, each one of these 'domains' is a standards war waiting to happen, and in the meantime lots of XML is being deployed now with custom homebrew schemas. It has enormous potential to interoperate better than proprietary formats, but it is not the magic solution to data interoperability

    This is what I noticed, and why it doesn't seem like XML is all that big a deal... if everyone is going to have their own formats/layouts anyway, it doesn't make much of a solution. Granted, it would make conversion filters far easier to write, but doesn't really solve a lot of things...
  • Hear, hear... I repeated the same thing somewhere else on this discussion and a coupla older ones: we need to clean up the config files mess. And I even would go one further: clean up man files as well. Man files are an anachronism; they are not hypertext --no links-- and are not easily searchable. When every machine has a browser builtin, why are we still dealing with man files? Let's move manuals to some SGML/XML/HTML based format, that can be viewed through a browser and make 'man' a parser of that format for the old folk.

    You could then even import annotations and errata on the documentation from the Net... look at how the PHP folk do their manual [php.net]. It's the future of documentation folks...

    But this is Open Source... let's stop bitching and day-dreaming; sit down and write code... who's hosting the CVS? ;-)...


    engineers never lie; we just approximate the truth.
  • Emacs (PSGML) is actually the best editor I know for XML files. It gives you context-sensitive pop-up menus of all the tags (or attributes) which are valid at any given point; makes it extremely easy to construct valid XML documents and actually quite hard ot construct invalid ones.

    I would be very much in favour of a gradual conversion to XML-based configuration.

  • Who else hear thinks of the TRS-80 [zeppelin.tzo.cc] when you hear OS/9 ? The famed UNIX lookalike for the Color Computer. I liked their version numbers: Level I and Level II. I'd like to see an Ars Technica retrocomputing article about OS/9 sometime....

    JD
  • by Anonymous Coward on Wednesday March 01 2000, @06:05AM (#1236027)

    Your question is not dumb in the least. Although I've heard a lot of hype about XML, I don't think I've ever seen a trade press article that explains how XML is going to save the world.

    My understanding of what the excitement is all about goes like this: XML provides a standard framework for meta-data across different application domain. Because the framework is standardized across domains, we can write the basic tools (e.g. parsers) once, and have them work for all the different domains (e.g. retail sales, medical records, flight schedules, whatver).

    For each domain, you have "experts" (in reality, probably just the largest companies in the domain) define a common way of expressing the data for that domain. This is formailzed as a DTD. Everybody publishes their data using that DTD, and now you can interoperate.

    That's my guess, anyway. I hope those who know more will be able to correct me. For one thing, I don't know how it is that XML is any more suitable for the purpose than its progenitor, SGML.

  • by Anonymous Coward on Wednesday March 01 2000, @05:33AM (#1236028)
    WebObjects 4.5 was released today. The new features (and server platform support) are interesting. A linux version would be interesting, maybe for 5.0.

    http://www.apple.com/webobjects/ [apple.com]

  • Which is that XML files are required to be valid.

    Supposing you mistag something in /etc/sendmail.xml , this could mean that Sendmail could no longer run.

    There is a benefit that XML buys you, which is that you could build a generic configuration tool that doesn't intimately know any individual DTD, but which does know how to:

    • Turn an XML document into a browsable tree on screen, and
    • Accept modifications and write them out as validated XML (sans DTD)
    But as you say, there would need to be many DTDs, which really just shoves the problems around a bit. It doesn't clean them up; it's more like using a dirty rag to clean a window, so that the dirt is getting redistributed to different parts of the window...

    The big problem would be in getting all the applications to change to use an XML parser.

  • by Matts (1628) on Wednesday March 01 2000, @04:22AM (#1236030) Homepage
    I knew I should have patented that idea when I posted the idea to the ICOA (Amiga developers) mailing list 2 years ago... damn!

    Seriously though - this is what it's all about - if you don't like the tools the OS provides, you can write your own, instead of being stuck in GUI hell. This is how an OS should be.

    MacOS X is looking seriously interesting.
  • by Taco Cowboy (5327) on Wednesday March 01 2000, @04:31AM (#1236031)


    If something takes a G4/350 and 256MB of RAM to run "smoothly", that something is obviously bloated.

    I have read ars-tech's report on OS X, and yes, I am impressed with the technology. I hope some form of it will eventually be implemented in the open-source arena - whether it be *bsd or linux doesn't matter - but we can forget about the bloatedness.

    This world still needs a slim-fast-and-robust OS. It may not be pretty, but as long as it works wonderfully, it will has its place.

  • ...but then I realized how pointless that would be. For instance, there's no good way to put, say, /etc/sendmail.cf AND /etc/hosts in the same XML format. So you'd make one type for each file. You'd end up in the same situation that we are in now: multiple formats with confusing structure with the added "bonus" of XML tags littering the file.
    --
    Here is the result of your Slashdot Purity Test.
  • by Dacta (24628) on Wednesday March 01 2000, @12:43PM (#1236033)

    XML allows you to write self describing files that are backwards compatibile.

    This sounds pretty useless at first, until you realize that it means that a tool can be written to adapt to changes in the file.

    For instance, if you have a DTD that describes the data on a person, you might the fields FirstName, LastName, and PhoneNumber.

    A GUI tool can read the DTD, and dynamically created edit fields for each one of those items.

    Now if you go and change the file, so it includes EmailAddress, the tool can cope with that change by creating a edit field for that, too.

    While you can do something like this with a simple text file with the field names along the top (for instance), the point is that the GUI tool you wrote for the first file will work for other XML files, too - with totally different DTDs.

    It has other benefits as well. Because you know from the DTD all the possible field types, you can write generic softwear that transforms the files in various ways. For instance, you can use XML Formatting objects (I think that is what they are called) to transform an XML file into a PDF file for publication, simply by defining how each tag type should look.

  • by DonkPunch (30957) on Wednesday March 01 2000, @08:08AM (#1236034) Homepage Journal
    This was actually the topic of an "Ask Slashdot" some time back. If I wasn't lazy, I'd dig up the URL.

    I'm all for XML Config files and any software I write in the future that requires a config file will most likely use an XML format. Of course, this will make me an oddball for a while.

    The problem with XML Configs on Linux and Unix in general is that the platform philosophy is to have multiple small reliable tools. It works, but each of the tools often requires its own configuration file. In the case of Linux, the maintainers of these tools are often working for free on their own time. First, they have to be motivated to convert their home-grown file parsers to XML (or link to xmllib). Then, they have to define a grammar for the configuration file. With XML, defining a good grammar is most of the battle.

    For developers who have become accustomed to "linefeed, parse, repeat", converting to XML is time that could be spent on bugfixes or new features.

    Also, if Apache, VIM, emacs, sendmail, and ftpd are all using XML files with different grammars, what has improved? We've traded one format for another, but not really improved consistency.

    And if you think new users are scared of space-and-linefeed delimited config files, wait until you show them tagged config files with less than/greater than signs all over the place! For XML to truly make configuration easier, it will require a graphical general-purpose configuration tool that reads a DTD for the config file and presents the configuration in a point-and-drool framework.

    The good news is that this can been done. I really hope it happens.
  • by doce (31638) on Wednesday March 01 2000, @04:57AM (#1236035) Homepage
    <i>If something takes a G4/350 and 256MB of RAM to run "smoothly", that something is obviously bloated.</i>

    Alas... every version of OS X consumer that's seen the light of day has had full debugging enabled at the (micro?)kernel, slowing the OS down considerably. Note that the current DP (Developer Preview) releases are purely to allow developers to have devices and apps ready to run under OS X... Apple isn't providing them with a polished OS.
  • by costas (38724) on Wednesday March 01 2000, @05:32AM (#1236036) Homepage
    All we'd need is a good DTD for Linux that will more or less follow the GNU options standard. Then, any application could extend the DTD for its own use.

    You don't really have to agree on one DTD standard to see immediate benefits. One centralized XML-system parser that would read config files from one centralized XML depository would solve so many installation issues it's not funny. Think about this example: you're installing say PHP. PHP needs to know where Apache and MySQL are. Instead of bothering you with setting up the --with switches, the configure script calls the system XML library with say application("apache").source.path If it can't find it, it will tell you you need to install it --hey it could even go on the web and look for it... And the possibilities for online documentation and remote administration are too numerous to mention...

    I think the two big issues with XML config files are: a) people think they're much uglier to edit than /etc files, b) most importantly, backwards compatibility. (a) IMNSHO is not an issue. Config files should be machine-readable first and human-readable second. Human-readability should only be important when things have gone wrong and you're SOL --under normal use you should use an XML aware config-tool (a meta-Linuxconf) to edit the files. Under emergency circumstances, you can still fire up vi and edit an XML file (unlike, say the Registry).

    (b) is trickier. This is what I have proposed in an older /. thread: Let's create a centralized config directory, say /conf and a backwards compatibility deamon that monitors changes in /conf files. When an application and/or user changes a /conf file, the deamon parses the changes and writes out the appropriate /etc or /var file. I.e. during the transition period, /etc and /var will be read-only and /conf both read and write.

    This is just a rough concept. But if there are any takers, let's do something about it... this is Linux people...


    engineers never lie; we just approximate the truth.
  • by spiral (42436) on Wednesday March 01 2000, @06:24PM (#1236037)
    OSX is not BSD! OSX is OSX. Well, actually, OSX is NeXTSTEP.

    The BSD that everyone keeps talking about is the unix interface. The OSX unix layer presents BSD compatible APIs, libraries, and tools; just like the classic layer presents MacOS classic APIs. OSX is BSD in the same way that SunOS was. It is not a derivative of {Free,Open,Net}BSD, it's just not System V.
  • by zorgon (66258) on Wednesday March 01 2000, @04:36AM (#1236038) Homepage Journal
    Great review. I have three impressions:
    1) MacOS is now MacOSNIX, as well it should be. I always thought A/UX kicked major PC butt, but in this I think I was alone in the world. C'mon, now all, you have to admit, Jobs was ahead of his time with NeXT ... (don asbestos suit now) ;)
    2) By doing stoopid stuff in Aqua like shuffling around the buttons on the bar and removing the Apple Menu, Apple is going to piss off many end-user type folks who stuck with Macs even when the OS stunk (and don't give a hoot about the kernel). Bad move, with little to argue for it. Pointless eyecandy.
    3) That XML idea for sorting out all those config files and scripts is great! Kudos to those who did it and those who've been saying it all along.

    "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off."
  • by anatoli (74215) on Wednesday March 01 2000, @04:48AM (#1236039) Homepage
    XML [xml.org] is such a misnomer.

    There is no X [x.org] support at all. Moreover, there's no ML [bell-labs.com] support at all! Please W3C [w3.org] change the name.
    --

  • by DreamerFi (78710) <(moc.ruetnis) (ta) (nhoj)> on Wednesday March 01 2000, @10:54PM (#1236040) Homepage
    And yes, that's indeed a standards war waiting to happen - but luckily for 'us programmers', that war is at a level of "are we going to call that field X or Y" and calling it either way is not going to impact our code at all, nor will it require changes in our code. Now compare this to the standards war where two parties differ on the interpretation of bit number X of field number Y, and every single change means grinding over the code again. Now I don't know about you, but once I've written something, it suddenly is a lot less fun writing it again, so if I can avoid that, that alone would already be a Good Thing. Another interesting feature is that once you've got a xml parser, any new communications with a new system doing basically the same thing (for example, another supplier for the widgets your manufacturing dept needs) will mean zero coding - just changing a DTD file.
  • by Greyfox (87712) on Wednesday March 01 2000, @04:03AM (#1236041) Homepage Journal
    At one point I mumbled something about XMLifying the /etc/filesystem -- right now there are too many different config file formats. Actually coming out with a standard XML reading dynamic library would allow a more standard formatting scheme.

    But... what we have now isn't really broken and I doubt you could persuade all those programmers to fix it.

  • by Carnage4Life (106069) on Wednesday March 01 2000, @03:50PM (#1236042) Homepage Journal

    XML is a data interchange format. Many legacy systems contain data in disparate formats, and with the advent of the internet lots of developers are working on various ways to connect these systems using the Internet. One of their challenges is to be able to exchange data between systems that ordinarily are not compatible. XML might be the answer. Since the XML text format is standards based (implying that many applications can understand it), data can be converted to XML and then easily read by another system or application. For instance it would be a whole lot easier for banks or insurance companies to trade information with each other (epecially over the internet) using an agreed upon XML standard than using conflicting proprietary protocols.

    Using XML for Web data. Imagine having an HTML page in which none of the content is located on the page itself. Instead, the content is stored in an XML file, and the HTML page is used simply for formatting and display. The content can be updated, translated into another language, or otherwise modified without an author ever having to touch the HTML code. :-)

    Using XML to create a common data store for information that might get used in many different ways. Suppose, for example, that you are writing an article for a magazine or publishing a research paper. The publisher also wants to include the article on a Web site and then submit it for inclusion in a book or journal. If the original article was authored in a proprietary format, such as Microsoft's Word format, the article would have to be reworked for the Web posting and then probably reworked again for the book or journal. If the article was written in XML, however, it could be published to the three different environments simultaneously because the data of the article is independent of how it is being displayed. The formatting, layout, and so on are dependent upon the application using the data and are not attached to the content itself. Furthermore, the application code that displays the data needs to be written only once, and it then can be used to display any number of articles.

    These are the three I can remember from all the XML books I've read in the past few months.
  • by burris (122191) on Wednesday March 01 2000, @08:50AM (#1236043)
    Quartz is less critical, though in the long run it will probably make life easier for developers. The fancy stuff there isn't strictly necessary, not yet, though as the range of displays increases, going to PDF and breaking the dependency on DPI and viewing distances will be necessary for the range of devices that Linux will run on.
    Quartz is actually much more critical than you suspect. Lets face it, the whole "raison d'etre" for Cocoa ("The Frameworks Formerly Known As NeXTSTEP, OpenStep, and Yellowbox), is to make the deveploper's life easier. Very powerful, intuitive, and advanced user intefaces can be done with Mac Toolbox, WIN32, Gnome/GTK, and even direct to X-protocol programming. It's all a matter of degree of difficulty for the developer (and by comparison to Cocoa, it's a serious PITA on the abovementioned platforms). As time to market and developer attention spans are at such a premium, a much more powerful developement environment (the frameworks and APIs, not fancy IDEs make the difference) allows developers to make much more powerful applications that really advance the state of the art of applications.

    Aside from the powerful graphics primitives and coordinate space transformations, you get real WYSIWYG display and printing for FREE! If you can display it on the screen then you can print it simply by sending a message to a print object. You get free output to PDF files. Anyone who has written a serious application that creates documents intended to be printed knows that the printing code is often a major PITA and a substantial portion of the time and effort expended to write the whole application. A lot of applications that aren't necessarily intended for creating printed documents don't have printing support or have extremely rudimentary printing support because it is so difficult.

    Furthermore, there is a thing known as "Filter Services" which are little bits of code that register with the OS indicating what file types they accept and what types they convert to. When you create an Open File panel you indicate what file types you want to accept (PDF for instance, which any app can display for free of course). There is already a PostScript distiller filter service that converts PS and EPS files to PDF. If the user has it installed on her system then PS and EPS files will show up in the Open File panel in your application. When they select them the file will be automatically converted to PDF. So even if your app doesn't directly support certain file formats, if there is a filter service available that can convert to one of your supported file formats then you get the additional formats without having to do anything, and without the user having to make an explicit conversion.

    So Quartz gives developers and users an amazing amount of power that lets them write extremely functional applications without much effort. This of course is translates to a direct benefit to users. It's more than just whizzy transparency...

    Dr. Burris T. Ewell

  • Their review is just phenomenal, profoundly clued. However, one thing that struck me about it was this: the criticism of the UI is that it is pure eyecandy, very good at that, but woefully unorganised and incapable of scaling up to a power user level.

    Well... that's a given. It's quite obvious. But might it be intentional? It seems to me the conventional wisdom is that usability does _not_ sell, and that flash is the only thing that drags in the consumers, many of which will never grow beyond basic web surfing and writing straight text in Word. Under those conditions the faults of OSX's GUI are not relevant, as the person would not be running two things at once except by accident (and guess what? for a change that would be instantly obvious!), and would never have learned any of the useful shortcuts of classic MacOS, whether it's ability to customise the Apple Menu or ability to do a contextual popup menu or use of the Control Strip. It's as if Aqua is designed to default to handhold the most relentlessly AOLish l^Huser. I'm not at all sure this _is_ a mistake.

    Then the trick becomes finding ways to replace the dock, to get rid of the default stuff and use other methods. Surely this is not going to be so hard given that Darwin is OSS and we'd be _replacing_ the proprietary GUI, not tapping into it? By that I mean shutting _off_ the Dock rather than altering it, I don't mean ditching Display PDF and running KDE on it. That said, I just bet one of the first replacements is somebody hacking a Windows taskbar and start menu only in Aqua style. Furthermore, I fear and suspect it will be a _jello_ taskbar and start menu, translucent, and will wobble sproingily at all times in a continuing bit of very striking but very distracting animation. (Why??? 'Because we can!' This becomes a hell of a lot simpler hacking Aqua and using a vector GUI.) But... why not? It's not like I'd have to use it. I might prefer something like a root menu, and tend to avoid having desktop objects at all, like I do in X and in MacOS. For me, icons are for keeping in folders in disks- the desktop should have only clippings and work in progress. If I could remove the drive icons in MacOS and get the windows through a popup or something, I would.

    There are a lot of things I like about Linux, mostly the freedom to be whimsical with the UI: I don't have to run a desktop if I don't feel like it. I can have taskbars of many different kinds, or not- I can have tiles and icons in many different ways, or not. However, I mostly run MacOS, partly because I know how to keep it running happy and stable, partly because its interface is more consistent (_especially_ text editing semantics- I'm sorry, X mouse text editing is crazed- even the 'windows imitations' are horribly inadequate compared with the traditional, post-Drag-and-Drop MacOS handling of it), partly because of access to tools. I write software for MacOS only- that is because it is a lot _easier_ to do, not because I don't want to code for Linux. I would really like to see some convergence here- in particular, I'd like to see OSX become popular in such a way that writing programs for it is closer to writing for Linux. Ideally I'd like to see some of the _great_ programming environments for MacOS (No I don't mean Codewarrior- I mean REALbasic. It's like a _really_ sophisticated GUI drag and drop object oriented interface builder only you code in Python- not really Python, but I'm told it's very Pythonish) evolve so they output code for OSX- at which point it becomes a lot easier for them to also output code for Linux.

    As these companies and programmers start adapting to a more Unix-based environment, they can start coexisting with the OSS world. There _are_ Mac programmers who 'get' open source. It's an active area- one of the biggest Mac gaming hits _ever_, Bungie Software's 'Marathon', recently saw GPLing- Marathon 2 was released under the GPL, and in just a few months has been substantially debugged and tweaked and enhanced, longstanding engine limitations totally obliterated in a delightful burst of free hacker effort. As the Mac converges with Linux (I consider the move to Darwin and BSD underpinnings a convergence all by itself), this sort of thing will happen more often. The end result might well be a massive cross-pollination- tons of Linux code being adapted for use with Aqua, tons of Mac programmers and vendors suddenly beginning to release stuff on Linux as well.

    When that starts to kick in, Windows can go pound sand >:)

  • by Wyatt Earp (1029) on Wednesday March 01 2000, @04:08AM (#1236045)
    The new Powerbooks are not that expensive when compared to another top of the line laptop like a Thinkpad.

    Powerbook - $2,499.
    14.1-inch TFT screen
    400MHz/1MB L2 cache
    64MB SDRAM
    6GB Ultra ATA
    DVD-ROM/DVD-Video
    8MB video memory
    10/100BASE-T Ethernet
    56K internal modem
    2 Firewire ports

    Thinkpad 600X - $3,299

    Intel® Mobile Pentium III 500MHz
    64 MB SDRAM
    12GB Hard Drive
    2 Type I/II or 1 Type III CardBus and Zoomed Video support slots
    13.3" 1024x768 -- TFT - active matrix
    24x max-10x min4 CD-ROM
    56K5 v.90 KBps Modem

    So yes the Thinkpad has a faster CPU (smaller cache) and a bigger HD, but theres no Ethernet in the Thinkpad, thats an option. Smaller screen in the Thinkpad and no DVD-ROM. If you jump up to the 500MHz Powerbook...you spend $200 more than on the IBM, but you get 128MB of RAM. Plus you are getting the 2 Firewire ports for video and storage. (and if you say..."theres no Firewire devices out there!!!" You need to close your mouth and open your eyes...cause theres alot of Firewire devices out there.)
  • by mfterman (2719) on Wednesday March 01 2000, @06:16AM (#1236046)
    Apple once again lurches into the forefront in key technical areas even if their user interface standards are slipping. Reading this article really makes me wish that Tog was still back at Apple. What he could do with the power of Quartz and all the things he could fix in the Aqua interface make me sigh with regret. I'm also regretful that Apple went with BSD instead of going over and contributing to the Linux movement, but I can understand their reasoning.

    Even so, this setup makes it quite clear that there is a lot that can be done in future releases of Linux. The main parts that strictly concern the Linux kernel involve Apple's cleanup of the system directory structure, it's reorganization of resources and the use of XML heavily for configuration files.

    The main problem with Linux for the masses is that managing system resources on a Linux system is nontrivial and really requires a trained system administrator. There are configuration tools that try to simplify it, but the lack of a standard configuration file format really cripples the effectiveness of these utilities. Also, the Linux filesystem really grew without systematic organization over various releases of Unix, rather than being planned out as a coherent and unified set of data files and a parser.

    The thing I really like most about OS X is the whole /System layout, at least the concept of it. Linux really needs to sit down and think out a new directory structure from scratch to organize all the files that are needed to run the operating system, along with a few elegantly constructed libraries and tools for manipulating those files.

    Such a porting sounds hideous but it can in fact be done in stages. A developer's release, probably Linux X.9 because the final result will be radical enough to warrant an point zero release, could create a filesystem like /System and over the course of various X.9.Y releases, move various system resources over to it.

    Backwards compatibility can be maintained by leaving the old /usr, /etc and other filesystems in place. /System would be where the operating system really lived and things like /etc/hosts could be created by special utilities from the XML files that contain host information. But the idea there is that would only be for legacy application support and developers would be encouraged to port to the new /System layout.

    Bundles are an elegant compromise between the necessity of having a bunch of files together to run a single application while at the same time giving a convenient single box to be handled from outside. Average users will use the box as a whole, advanced users can open it up and play with the contents. This is another feature that Linux needs to come up with some equivalent for, if it is to succeed on the desktop.

    Quartz is less critical, though in the long run it will probably make life easier for developers. The fancy stuff there isn't strictly necessary, not yet, though as the range of displays increases, going to PDF and breaking the dependency on DPI and viewing distances will be necessary for the range of devices that Linux will run on.

    Unix wasn't so much designed as it evolved, and parts of the system show that. Apple has done a major boon by showing what Unix can evolve into, giving the Linux developers a clear target to aim at for their course of future evolution. Between /System, XML resource files, bundling and Quartz, Linux has plenty of ideas to copy and improve on through the open source movement.
  • by Tower (37395) on Wednesday March 01 2000, @05:26AM (#1236047)
    I've read a lot about how XML is the greatest thing since sliced bread, apparently enabling many different things, from website interoperability, office documents, making toast & eggs, an XML parser in the core of OS X, and now people are talking about making /etc/ files XML... I don't get it. Not just the /etc stuff, I don't understand what the big deal is about XML. It doesn't seem like the big panacea that will cure all of our standards problems and create world peace that many people seem to be making it out to be. In fact, I don't see very many reasons why I'd use it for *anything*...

    This is an honest request for information - please enlighten me.

    Thanks!
  • by imac.usr (58845) on Wednesday March 01 2000, @04:49AM (#1236048) Homepage
    I just saw this [cnet.com] on cnet, talking about Sun's new API for XML support - so, since Java support in OS X is supposed to be much improved, how long before somebody creates a Java-based configurator tool for OS X? If I had better Java skills, I'd be working on one myself.

    And if the JVM improves for Linux, how hard would it be to port such a tool? Not very, I'm guessing.

  • by Neville (88610) on Wednesday March 01 2000, @05:27AM (#1236049)
    Using XML to hold configuration data is sleek, but the possibilities for extending such translation to widget and component creation are even more promising:

    What if there were to be some XML processor built into the OS XML engine that parsed tags for creating windows, creating layout managers, and painting buttons, menus, etc. Assuming such components manage their own event processing and are truly modular (such as javabeans), one could script the creation of an entire UI or application. Maybe other API's could be mapped through XML processors and DTD's -- for instance, a series of XML tags mapped to OpenGL calls could be pretty spectacular.

    Granted, this is what scripting languages really already do: interpret chains of characters and map them to native machine functions. XML is the ultimate scripting language, though, because instead of choosing between perl, python, or even C, and being limited to their specific API's and syntaxes, we could simply use XML and choose different processors and DTD/controllers to accomplish the necessary mappings to specific syntaxes and API's. A single XML-crafted application could actually map to several languages if necessary, blending Java, C, perl, etc.

    Of course, a very talented team of brains would need to create the API-mapping-stylesheet-DTD pieces for these XML app developers to use, not to mention the XML processors (which would in effect become a virtual machine).

  • by stab (26928) on Wednesday March 01 2000, @04:09AM (#1236050) Homepage
    Well, the expat [jclark.com] library already exists and seems to be quite defacto under Unix.

    At least, PHP and Apache use it, and well. And a couple of other utilities and CPAN modules. I've come across. It's fast, small, and not full of unneccessary crap.

    Anyway, utilities like Apache [apache.org] and ProFTPD [proftpd.net] already have meta XML config scripts, and a fair few perl scripts that make use of XML::* as well.

    I don't think I like the idea of having a dynamic XML library, and your entire /etc filesystem depending on it. What do you do when it breaks? It's like screwing up your LD.so.1 ... ow :)

    Still, a standard, easy to use DOM for utilities would be nice, perhaps some kind of extension of the GetOpt stuff would work? It's succeeded largly because it's there and easy to use, and an XML standard would have to do the same.
  • by tjwhaynes (114792) on Wednesday March 01 2000, @04:30AM (#1236051)

    When I first heard about the Mac OS X GUI I was both impressed by the visually clean and clear appearance of the interface and the use of transparency to improve the relationship between sub-windows and the 'main' window. Reading through this Ars Technica article though, I begin to wonder whether all these special effects included with Mac OS X are an improvement to the original Mac interface or whether they are crucifying their principles of simplicity of use in order to appear more flashy.

    For example, the Dock bar at the bottom of the screen which progressively shrinks as you add more items to it and magnifies the few documents around the mouse when you move to it. This looks like a neat idea at first, especially when you look at the example screenshots given on Apple's site. But distinguishing between even 10 text documents is difficult using this method (the icon reflects the real document) and the example given of 1000+ documents in the bar in Ars is a nightmare!

    The use of a button on every title bar to switch between single and multi-window mode is also odd. I guess this is a more interactive way of minimizing windows for the new user, but it's strange to see an option like this as a window button everywhere.

    Don't get me wrong - I'm impressed by much of what I see in the Mac OS X GUI. The clear use of colour - i.e. generally neutral colours for windows, with primary colours for important window tool buttons on the active window - along with the Quartz technology and the XML integration are all worthy additions to the interface. But I do worry that some of the features are more a triumph of style over substance when it comes to real usability. As GNOME and KDE move to improve their interfaces, there is much to learn from the way Apple has designed their GUI. As long as nobody forces me to use a one-button mouse ...

    Cheers,

    Toby Haynes