No, they were opening in QuickTime just because they were originally saved by QuickTime.
No one ever did Get Info.
It sounds like this previous behavior seems odd to you (since you misunderstood what happened), which supports the perspective that for most users, the behavior was odd and the change amounts to a bug fix.
The use of XML at Apple is both interesting and sad, but also I think reflects the broader problems with how XML is (mis)understood and (mis)used.
Apple took the really clean OpenStep Property List format, which is very very similar the JSON format people are adopting today, and for some reason decided it needed "modernized" by using an XML-based format. To understand why this is so bad, let's look at the before and after versions, using an excerpt of real-world data from the Mac application OmniGraffle. Before:
{ Class = LineGraphic; ID = 4; Head = { ID = 3; }; Tail = { ID = 2; }; Points = ((225.5, 94.5), (296.5, 94.5)); Style = { stroke = { CornerRadius = 5; HeadArrow = FilledArrow; TailArrow = "0"; }; }; }
And this is the same data in Apple's XML property-list format:
(Sadly Slashdot ate all my nice formatting spaces which made both versions prettier, but was much more necessary for the XML version than the OpenStep/JSON-ish version.)
The XML version is less easy to read and considerably more bloated. What was gained over the original format? Very little. Apple's Property Lists are an example of really poor use of XML.
But at least XML is extensible you say! Not for property lists. Apple has a special custom parser in core foundation that just parses XML property lists, not general XML. Part of the reasoning for that might be that XML parsing libraries are fairly heavyweight and things like the kernel need to read property lists. But no one stopped and said “Wait a moment, we're writing a custom parser, it's not extensible, this usage isn't markup, it's data serialization and/or human-readable configuration files, so is XML the answer?”
But Apple's “not getting” XML doesn't stop with property lists. Anyone who thinks property lists were an aberration or thinks XML automatically equates with human readability should take a look at the XML produced by Apple's iWork applications (Keynote, Pages, etc.). It's barely readable—you need to be a masochist to wade your way through the grotesquely tangled and verbose mess. It is, in essence, a dump of the internal data structures used by their applications. And it isn't (easily) writable by anyone except Apple, because only they know exactly what the rules are for the composition of their XML format. Want a DTD? Dream on. Want to use XSLT and friends? Good luck!
XML does have its place, but before choosing XML as a format, you should understand the trade-offs involved in that choice. Know when you should use XML, how you should use it, and what the alternatives are. In particular, be aware of
The reasons XML wins over the alternatives. Can you give an informed argument as to why you shouldn't jus
The joke is saying the person "WANTED" to stay in the lab all night. Not that they had too. Not that it was expected.
The original poster said:
An engineer (well, one lucky enough to get the opportunity!) might feel guilty about cheating on his/her spouse... but never about spending a night at the lab!
That's a pretty clear statement.
If the way you express your passion is by working all night, and doing so is productive, great for you. But it seems like some of the people who replied to my post can't even imagine how someone could be passionate about their work but less willing to stay all night, and that really is a pretty sad failure of imagination. Perhaps the best person for the job is a passionate go-getter who has to manage other responsibilities besides work, or perhaps it's someone who can blitz for six hours but then needs to take a break. The fact that you would express your interest and devotion to a project by abandoning sleep and other responsibilities doesn't mean that that approach is the only way to do so.
Sure, someone who's a genius, has no other responsibilities besides their job, can work 16 hours straight, day-in day-out, yet showers, has good social skills, can lead and be a team player, can focus but can also see the big picture, etc. might be be great. But there are very very few people who are perfect at everything. Why should you make the person who is a genius but has other responsibilities feel like they are less of an engineer than a technically weaker person who'll get less done but loves to lose sleep doing it? When someone says, "An engineer never does X", and you are someone who does do X, that person is telling you, "You are not an engineer".
Anyone who thinks that's a "sexist" joke isn't a good engineer, because they've never experienced a problem so engrossing that they'll spend all night trying to solve it. An engineer (well, one lucky enough to get the opportunity!) might feel guilty about cheating on his/her spouse... but never about spending a night at the lab!
You're wrong in thinking jokes like this are completely innocuous. Sending the message that "good" engineers are the ones who'll stay all night is exactly what keeps people who value life balance out of fields like engineering. Such a culture doesn't just tend to exclude women, but also people from non-anglo cultures that value family.
If you're a really a good engineer, perhaps you don't need to stay all night. Perhaps you can manage your time, estimate things well, or perhaps you can just solve solve the problems that take other people sixteen hours in only four. Perhaps you recognize that going out and being in the world, doing other things will give your subconscious a chance to chip away at the problem. Perhaps you realize that taking a shower and being fresh for tomorrow's big presentation is much more important than doing one more tweak to the already working prototype.
A culture that projects a limited idea of kinds of people that might make good engineers needlessly turns away good engineers who don't fit the mold. You also risk creating a monoculture that will never even think of the best designs.
A lot of the comments here seem to say something along the lines of
If undarstand me you can, than understood he message was, and so quite you're compainin'
The mistake is to not realizing that in bad writing, the understanding part is not effortless. You waste your readers' time. If it costs each of your readers just two seconds more to read your badly written prose, how many readers do you need before the waste of their time outweighs what you see as a waste of yours. Precious few! If it takes you a minute to correct your grammer, fix that typo, or add an actual link to the website you've just mentioned, you may have saved tens of minutes of everyone else's time.
And you'll save us all wasting yet more minutes wading through responses to your post that merely complain about your grammer, post the missing links, and generally complain about or fix the things you were too lazy to do.
(Same applies to email, where too many people love emailing everyone a "memo" in the form of an attached a.doc file, saving themselves all of a second's worth of copy and paste...)
In my office, across from my new 2GHz dual G5, I have a 1991 NeXT Workstation. Admittedly, I don't have it on all the time anymore, but I do turn it on once in a while to convert old WriteNow files and such. (Until July 2001 it was my main machine and in use daily -- I had to wait until OS X before there were machines up to the task of replacing it.)
These days, one of my favorite uses of the machine is doing a side-by-side comparison with OS X. I compare the supplied Terminal, TextEdit and Mail applications on OS X and NeXTSTEP, showing that they're essentially the same programs, including details like the Font Panel and Color Picker. I then run OmniGraffle (2.0) on the Mac and Diagram.app on the NeXT -- again the two are essentially the same (OmniGraffle began as a Diagram clone and will read Diagram files). Finally, I run Abscissa (a graph-drawing program) on both and open the same file and show that it's exactly the same third-party app, just recompiled. Along the way I show things like live window dragging. It's pretty easy to see how OS X is in large part a continuation of NeXTSTEP.
The NeXT is, of course, a little slower, but people tend to be surprised when I reveal that the NeXT has a 25MHz CPU, whereas the G5 has two 2000MHz CPUs (factor of 160 difference), the NeXT is maxed out at 32MB of RAM, whereas my G5 is only at 3/16ths capacity at 1536MB (48x more), and the NeXT has a 1GB internal drive whereas the G5 has a 160GB drive (another factor of 160). The NeXT is more than twelve years old and nevertheless holds its own pretty well -- it certainly doesn't seem like 1/160th of the machine my G5 is.
Sadly, these days it takes a couple of tries before the internal 1GB hard drive spins up, and so I think one day it's going to go to that place in the sky that disk drives go to. That'll be a sad day, but not one I can't recover from -- at only 1GB, it's not like it takes much space to store a backup.:-)
In Mach, device drivers are IOKits ( Input-Output kits).
No. In Darwin there is an Embedded-C++ framework called IOKit for writing device drivers. It doesn't come from Mach (Mach is written in C), it is a masterpiece of design that was written from scatch at Apple, inspired by DriverKit, which was an Objective-C framework with the same intent. (Yes, NeXT put Objective-C in the kernel. At the time, they were running on PC hardware and needed a way to write drivers that minimized developer time.)
The differences between a Microkernel, like what is used in Mac OS X and Darwin, and a Monolithic Kernel... a Microkernel consists of small message passing cores or Modules, with several different Daemons or "servers" that communicate between the modules
No. Darwin does not use Mach as a microkernel, and neither did NeXT's kernel. Mach is used in Darwin because it provides an excellent core for the OS with a clean API. But given the way it shares its address space with the BSD layer and IOKit, you cannot call the Darwin kernel a Microkernel.
Yes, Mach makes it easy to have a chunk of a device driver out in user space, and Apple encourages developers to do this when they can, but some Linux device drivers do that, too.
In my opinion, IOKit is what makes Darwin special. The way it uses inheritance and its concepts of drivers having different interrelationships on different `planes' (e.g., power, USB topology, code dependencies, etc.) make it easier to write drivers and support things like dynamic device attachment and power management that Linux still struggles with.
The Mac OS X's malloc library has built-in support for providing good leak detection. The command line tool leaks (installed with the
free developer tools). Although leaks can be run on any program, it works best when you set the enviromment variable MallocStackLogging, which causes the system to provide complete stack frame information about when each piece of leaking memory was allocated.
Also of interest are the malloc_history and heap command-line tools. They tell you lots of interesting information about exactly what is on the heap and how it got there. The malloc library also detects double frees by default (making it immune to the recent zlib security vulnerability) and can also detect writing on free blocks, etc. Very nice.
Finally there is a graphical application, MallocDebug which provides similar information on memory leaks and memory use but also provides an easy to use memory-browser interface. Unlike simple leak detectors, you can explore your program's memory space and discover memory that isn't strictly "forgotten" by your program (it still has valid references to it) but should perhaps have been deleted anyway (e.g., finding memory allocated for a splash screen graphic). This last application requires that the code use a special library, but it is easy enough to make dynamically-linked programs use this library (thanks to Darwin's equivalent of LD_PRELOAD, DYLD_INSERT_LIBRARIES).
Although you can debug any code with these tools (from command-line tool to X-windows, Carbon or Cocoa app), they really shine debugging Objective-C, because Objective-C provides enough runtime information for the tools to tell you lots about the objects that are sitting there on the heap.
Apple's orginal announcement has a few more detail
on
Apple Updates The APSL
·
· Score: 4
Here's Apple's announcement of their changes to the APSL. It has a few more details of what has changed.
From: Ron Dumont <rond@apple.com>
To: publicsource-announce@lists.apple.com
Subject: Apple Public Source License version 1.2
Date: Thu, 4 Jan 2001 16:26:17 -0800
Message-Id: <200101050026.QAA18128@scv2.apple.com>
Hello,
We are pleased to announce version 1.2 of the Apple Public Source License.
We made several changes to better serve and protect the community that
has evolved around Darwin and other Apple Open Source projects. The
major changes are:
* You no longer need to distribute modifications made for personal use
(sections 1.4 & 1.8)
* You are no longer required to notify Apple when you deploy modifications
(previous section 2.2(c) deleted) -- though the notification site
will remain for those who want to use it.
* The Infringement / Suspension clause (previous section 9.1) has been
removed; you are now responsible for securing all necessary rights
yourself (section 2.3)
* Many of the license terms have been rewritten to also protect
Contributors, e.g., section 10 (the Trademark protection clause)
now covers trademarks and tradenames of any Contributor as well as
those of Apple.
We've also made numerous other changes to streamline and clarify the
license, so we encourage you to read it yourself at
http://www.opensource.apple.com/apsl/. We welcome your comments at
opensource-admin@group.apple.com. You are also invited to discuss the
APSL on the Open Source Initiative's license-discuss list. To subscribe,
send an email to license-discuss-subscribe@opensource.org.
We would like to thank the people outside Apple who helped us improve
the APSL to better serve the community.
The upside is that RedHat's gcc snapshot generates better code,
thanks to the powerful new optimizations it
contains. It also fixes some bugs in 2.95.x
and works much, much better on RISC platforms.
Hardly surprising given that it contains about a year's worth of development effort over gcc 2.95.x.
It's all very well for the gcc steering committee to take the attitude that gcc 3.0 will be done when it's done, but for those of us who want both a working compiler and one that has (almost) all the latest enhancements, RedHat's QA'd gcc snapshot is an absolute boon.
Lossy compression schemes such as Ogg Vorbis and MP3 work by removing sound that humans cannot perceive from the sound sample to improve the compression ratio.
Watermarking, on the other hand, adds sound information that human listeners supposedly will not be able to notice, but which machines will be able to detect. (And be able to perform this detection on any recording without being able to compare the watermarked stream against the original.)
These goals are in conflict. The only way that watermarks can be sure that compression technologies (including future ones) won't remove an inaudible watermark (on the basis that it won't be missed by the listener) is to design a process that uses an audible watermark. Thus, some people (hi-fi buffs, sound engineers, etc.) will be able to hear the difference between a watermarked and unwatermarked recording.
And, of course, most people will think they can hear the difference, and be unwilling to buy SDMI music.
Where do you get the idea that mach is a monolithic kernel? Mach is a microkernel, albeit a very outdated one. HURD is not a microkernel. HURD is a set of user space servers that run on top of a microkernel, namely the aforementioned mach. Darwin is essentially FreeBSD 3.x running on top of mach.
The Hurd uses a Mach microkernel. Darwin uses Mach, but not as a microkernel (just like NEXTSTEP and OpenStep before it). Go read about it.
This all makes me wonder. FreeBSD runs on x86, then Apple comes along and ports it to the PPC. Then they
release it as open source and a bunch of hackers start porting it to the x86. Is there really an advantage to
having a BSD running on mach?
If it were just FreeBSD on Mach, you might have a point, but it isn't. Take a look at how drivers are written using IOKit, dyld, netinfo, the vm subsystem, the unified buffer cache, etc. for just a few of the many differences.
Especially since mach is notoriously slow. Why?
Mach is ``notoriously slow'' when core functionality is implemented as user-space servers. Performance is why Darwin puts this core code in kernel space.
Darwin is still in its earliest stages on x86. If you miss the
early days of Linux and *BSD, you might enjoy helping get Darwin
going.
If you want to try Darwin for yourself, you'll need
A recent PC (440BX motherboards seem to work; 440FX motherboards don't)
A video card that has a VESA 2.0 compliant BIOS (ATI Rage 128, ATI Rage Pro, and Diamond Stealth III S500 are known to work; the ATI Mach64 GX and the simulated video provided by vmware are known not to)
A disk with about 450 MB free (and don't try using the end of a huge disk -- that won't work)
A fast Internet connection
An Intel i82559 network card if you want 'net connectivity (e.g., Intel EtherExpress Pro/100+ Management card)
Once you have that hardware, you need to download two images: one for a partition of
type AB (20 KB compressed) and one for a partition of
type A8 (about 100 MB compressed). Create appropriately sized partitions on your disk (945 blocks and 920304 blocks respectively), and uncompress the images onto those
partitions (I used primary partitions; extended partitions might work,
too) and try to boot. You can either use lilo, or download a Darwin boot sector.
If you can boot Darwin, then you can begin to explore. If you
like to hack on a new OS, or would like to see how Apple's idea of
Mach (monolithic kernel) differs from that of the Hurd (microkernel),
or even if you'd just like to see things done a different way (e.g., dyld
vs. ld.so, netinfo vs. NIS, IOKit vs. ????, etc.), Darwin can be pretty interesting.
For more information on on Darwin, check out Darwinfo or Apple's darwin-devel mailing list.
They forgot Water Joe! (Spring Water + Caffeine)
on
Caffeine Vault
·
· Score: 1
Want caffeine with without all that other baggage (sugar, color, etc.)? Want to make your own custom drinks with caffeine (e.g., caffeinated orange juice from frozen concentrate)?
Well, a while back I discovered Water Joe. Each 17oz bottle has 60mg of caffeine (and they now do larger bottles too). It's a bit more expensive than cola, but hey...
3Dfx All hardware supported in 3.3.6 is also supported in 4.0.1.
3Dlabs All hardware supported in 3.3.6 is also supported in 4.0.1.
Alliance The AP6422 is supported in 3.3.6 but not fully in 4.0.1. The AT25 is supported in 4.0.1 but not in 3.3.6.
ARK Logic No ARK Logic chips are supported in 4.0.1.
ATI All chips supported in 3.3.6 are supported in 4.0.1 except for Mach8 and some old Mach32 chips. The support in 4.0.1 is, however, unaccelerated for all chips except the Mach64, Rage and Rage 128 variants.
Avance Logic No Avance Logic chips are supported in 4.0.1.
Chips and Technologies All chips supported in 3.3.6 are also supported in 4.0.1.
Cirrus Logic The following chips are supported in 3.3.6 but not in 4.0.1: 6410, 6412, 6420, 6440, 5420, 5422, 5424, 5426, 5428, 5429, 6205, 6215, 6225, 6235, 7541, 7542, 7543, 7548, 7555 and 7556.
Compaq/Digital No Compaq AVGA support in 4.0.1. DEC TGA support is equivalent in both versions.
Cyrix No Cyrix chips are well-supported in 4.0.1.
Epson No Epson chips are supported in 4.0.1.
Genoa No Genoa chips are supported in 4.0.1.
IBM The standard VGA core is supported in both versions, but there is no support for the 8514/A or XGA-2 in 4.0.1.
IIT No IIT chips are supported in 4.0.1.
Intel The i740 and i810 are supported in both versions, but the i810 is only supported on Linux/x86 platforms at present.
Matrox All chips supported in 3.3.6 are also supported in 4.0.1.
MX (???) No MX (???) chips are supported in 4.0.1.
NCR No NCR chips are supported in 4.0.1.
NeoMagic All chips supported in 3.3.6 are also supported in 4.0.1.
NVIDIA All chipsets supported in 3.3.6 except the NV1 are also supported in 4.0.1.
Number Nine No Number Nine chips are supported in 4.0.1.
Oak Technologies Inc No Oak chips are supported in 4.0.1.
Paradise/Western Digital No Paradise/Western Digital chips are supported in 4.0.1.
RealTek No RealTek chips are supported in 4.0.1.
Rendition/Micron All chips supported in 3.3.6 are also supported in 4.0.1.
S3 Only the ViRGE and Trio3D chipsets are supported in 4.0.1. All of the other chipsets are only supported in 3.3.6.
Silicon Integrated Systems (SiS) Support for the 86C201, 86C202, 86C215, 86C225, 5597 and 5598 is currently only available in 3.3.6.
Silicon Motion, Inc No SMI chips are supported in 4.0.1, but the fbdev driver is reported to work on Linux.
Trident Microsystems The following (older) chipsets that are supported in 3.3.6 are not supported in 4.0.1: TVGA8200LX, TVGA8800CS, TVGA8900B, TVGA8900C, TVGA8900CL, TVGA9000, TVGA9000i, TVGA9100B, TVGA9200CXr, TGUI9400CXi, TGUI9420, TGUI9430DGi.
Tseng Labs All cards supported by 3.3.6 are also supported by 4.0.1 except for the old ET3000.
Well, I realize that's a risk, but I'm just protecting my personal box [with PortSentry]. It's not like I'll inconvenience my users (I don't have any). I figure that my box will look unintersting enough that they'll go away. Whenever an IP is dropped, I get an email, so I'm aware of what's going on, and I can fix it if I need to.
Do you have any suggestions for a better way?
I prefer snort. It logs attack attempts, but doesn't do the blocking that PortSentry does. Snort is very configurable, and can log a good deal of information.
The question I have (which I've been thinking of submitting to Ask Slashdot) is what to do with the lists of attacker IP addresses. I'm sure these are mostly just ``innocent'' compromised hosts, but it would be nice if there were some organized way for us to keep track of who those hosts were, so that people who were concerned about security could blacklist them.
Of course, there would need to be a way to ensure that the reported IP addresses are genuinely attackers (otherwise script kiddies could just submit claims that you were hacking them). Maybe Advogato's method for establishing a trust network could be adapted to the problem?
FreeBSD and BSDI's BSD/OS codebases *will* merge!
on
The Roots Of BSD
·
· Score: 2
``nik'' claims that ``FreeBSD and BSDI have not merged'', and that Andrew Leonard had been in error reporting that they had. But I think saying they'll merge is a good enough synopsis of the situation:
There's big news in the BSD community today, as two important mergers are occurring. First, Berkeley Systems Design, Inc., better known as BSDI, and Walnut Creek CDROM, the primary backer of FreeBSD, are merging. The combined company, BSD Inc., will have a strategy of promoting BSD on all levels. This merger, combining the two primary corporate supporters of BSD, will allow the new company to really focus its efforts on the improvement and promotion of BSD.
The other merger is that of the codebases of BSD/OS and FreeBSD. This merger will occur over (hopefully) the next year and result in a single operating system, still named FreeBSD. FreeBSD will remain completely open source and primarily under the BSD license, as it is today. Certain commercial drivers and components of BSD/OS which remain under NDA will be administered by BSD Inc. as add-on components. These components, along with the commercial backing, will be the value-added features separating FreeBSD from BSD/OS, which will continue as a commercial product (with FreeBSD at the core).
Hmm, this Microsoft innovation looks like it does exactly what my `linksame' Perl script has been doing for years.
Typically, I run find . -name '*.eps' -print | linksame to be sure the links it wants to make are sane, then find . -name '*.eps' -print | linksame | sh to actually do the linking.
Anyway, for anyone who'd like to have this `innovation' on their machine, here's the script: #!/usr/local/bin/perl -w
use strict;
my %sizes;
while (<>) { chomp; my $size = (lstat $_)[7]; ++$sizes{$size}{$_} if (-f _ and $size > 0); }
while (my ($size, $filehash) = each %sizes) { my @files = keys %$filehash; next if @files < 2; my %sums; foreach my $file (@files) { $file =~ s/([\s\\<>&;\{\}\[\]\(\)])/\\$1/g; # Quote shell metachars (my $sum, undef) = split ' ', `md5sum $file`, 2; warn "Couldn't sum $file\n" unless length $sum == 32; push(@{$sums{$sum}}, $file); } while (my ($hash, $same) = each %sums) { next if @$same < 2; my $first = shift @$same; print "chmod ugo-w $first\n"; foreach my $other (@$same) { if (system("cmp", $first, $other) != 0) { warn "files $first and $other look the same but aren't\n"; next; } print "ln $first $other\n"; } print "\n"; } }
For those who want to know what is actually new in Perl 5.6, you want to look at perldelta. (The message linked to above is just what was new since the last beta).
Re:My 2.something cents CDN
on
MacOS X DP3
·
· Score: 3
So how hard *IS* it to do most of that stuff? In March we'll have an XFree that incorporates hardware acceleration standard. GNOME already has libraries in it that do transparency/animated buttons (gdk-pixbuf).. Who's to bet we couldn't do all this, at a minimun cost to CPU?
It's a mistake to conclude that once you have something that looks like NEXTSTEP (or some other OS), you will have something that is like NEXTSTEP (or some other OS).
Sure, it's lots of fun to play with The Gimp and make some skins. But there are plenty of things beneath the surface that aren't glamorous but have a huge impact on usability. The imaging models that are integrated into NEXTSTEP and Mac OS X make a huge difference for developers, making it easy to develop applications that can produce high quality printed output as well as excellent screen output. Similarly, having a pasteboard that can handle images, mail messages, line art, and so on -- seamlessly -- makes life easier for users and developers alike.
Most people who think it's easy to imitate NEXTSTEP have never actually used the system for any length of time, and have never taken a look at the `under the hood' complexities the GNUStep project is tackling in their attempt to bring some of the underlying functionality of NEXTSTEP to other OSs.
Finally, just because the concepts embodied in NEXTSTEP (like its imaging model) are several years old doesn't make them outdated, irrelevant, or easily imitated today. On my desk I have two machines: a cool dual processor PC running RedHat 6.1, and a 25Mhz NeXTstation that's about nine years old. I do most of my work sitting at the NeXTstation. I think that speaks volumes.
Gary Krackow makes an unusual choice in naming electric hand dryers as one of his favorite gadgets. I have met few people who don't feel something akin to annoyance as they stare at the World Dryer Corporation propaganda that reads:
To Serve you better -- We have installed Pollution-Free Warm Air Hand Dryers to protect you from the hazards of disease which may be transmitted by towel litter, This quick sanitary method dries hands more thoroughly prevents chapping -- and keeps washrooms free of towel waste.
Every time I read this I am tempted to print up a label to stick over these claims, saying something like:
As a cost-cutting measure, we have eliminated a key reason for any staff member to examine this room by installing this device instead of the paper towels you would prefer. This slow awkward method prevents you from washing your face or wiping spills from your clothes, but is carefully timed to leave hands damp enough to provide a suitable breeding ground for disease organisms.
For more on the evils of hand dryers and commentary on various other minutiae of existence, I heartily recommend Nicholson Baker's The Mezzanine.
As I understand it, Linux's memory subsystem has seen a major overhaul in 2.3 to correct some early design flaws.
Some people seem to think Linux still has design flaws. (I see people in the BSD and fledgeling Darwin communities claim that their kernels are have a better architecture than Linux, although I rarely see much substantiation of these claims.)
So, are these people zealots, too deeply invested in their operating systems to face the truth that Linux is at least as good, architecturally; or were they right once, but the architecture problems have been resolved in 2.3; or are there still architectural weaknesses in Linux 2.3.
If so, what are these weaknesses and how serious are they? And how would you answer if we were comparing Linux's architecture to that of a commercial OS like Solaris.
So, basically, as you look at Linux, do you see parts of the code where you think `If we had it to do over again, we'd never do it like *that*'. And do you think Linux is any worse than other operating systems in that regard.
Slashdot Mirror
It's very cool the way this code draws a maze, but there's obviously a loop there.
(And it's “without” not “with out”, and “complicated” not “complicate”.)
No, they were opening in QuickTime just because they were originally saved by QuickTime.
No one ever did Get Info.
It sounds like this previous behavior seems odd to you (since you misunderstood what happened), which supports the perspective that for most users, the behavior was odd and the change amounts to a bug fix.
The use of XML at Apple is both interesting and sad, but also I think reflects the broader problems with how XML is (mis)understood and (mis)used.
Apple took the really clean OpenStep Property List format, which is very very similar the JSON format people are adopting today, and for some reason decided it needed "modernized" by using an XML-based format. To understand why this is so bad, let's look at the before and after versions, using an excerpt of real-world data from the Mac application OmniGraffle. Before:
And this is the same data in Apple's XML property-list format:
(Sadly Slashdot ate all my nice formatting spaces which made both versions prettier, but was much more necessary for the XML version than the OpenStep/JSON-ish version.)
The XML version is less easy to read and considerably more bloated. What was gained over the original format? Very little. Apple's Property Lists are an example of really poor use of XML.
But at least XML is extensible you say! Not for property lists. Apple has a special custom parser in core foundation that just parses XML property lists, not general XML. Part of the reasoning for that might be that XML parsing libraries are fairly heavyweight and things like the kernel need to read property lists. But no one stopped and said “Wait a moment, we're writing a custom parser, it's not extensible, this usage isn't markup, it's data serialization and/or human-readable configuration files, so is XML the answer?”
But Apple's “not getting” XML doesn't stop with property lists. Anyone who thinks property lists were an aberration or thinks XML automatically equates with human readability should take a look at the XML produced by Apple's iWork applications (Keynote, Pages, etc.). It's barely readable—you need to be a masochist to wade your way through the grotesquely tangled and verbose mess. It is, in essence, a dump of the internal data structures used by their applications. And it isn't (easily) writable by anyone except Apple, because only they know exactly what the rules are for the composition of their XML format. Want a DTD? Dream on. Want to use XSLT and friends? Good luck!
XML does have its place, but before choosing XML as a format, you should understand the trade-offs involved in that choice. Know when you should use XML, how you should use it, and what the alternatives are. In particular, be aware of
The original poster said:
That's a pretty clear statement.
If the way you express your passion is by working all night, and doing so is productive, great for you. But it seems like some of the people who replied to my post can't even imagine how someone could be passionate about their work but less willing to stay all night, and that really is a pretty sad failure of imagination. Perhaps the best person for the job is a passionate go-getter who has to manage other responsibilities besides work, or perhaps it's someone who can blitz for six hours but then needs to take a break. The fact that you would express your interest and devotion to a project by abandoning sleep and other responsibilities doesn't mean that that approach is the only way to do so.
Sure, someone who's a genius, has no other responsibilities besides their job, can work 16 hours straight, day-in day-out, yet showers, has good social skills, can lead and be a team player, can focus but can also see the big picture, etc. might be be great. But there are very very few people who are perfect at everything. Why should you make the person who is a genius but has other responsibilities feel like they are less of an engineer than a technically weaker person who'll get less done but loves to lose sleep doing it? When someone says, "An engineer never does X", and you are someone who does do X, that person is telling you, "You are not an engineer".
You're wrong in thinking jokes like this are completely innocuous. Sending the message that "good" engineers are the ones who'll stay all night is exactly what keeps people who value life balance out of fields like engineering. Such a culture doesn't just tend to exclude women, but also people from non-anglo cultures that value family.
If you're a really a good engineer, perhaps you don't need to stay all night. Perhaps you can manage your time, estimate things well, or perhaps you can just solve solve the problems that take other people sixteen hours in only four. Perhaps you recognize that going out and being in the world, doing other things will give your subconscious a chance to chip away at the problem. Perhaps you realize that taking a shower and being fresh for tomorrow's big presentation is much more important than doing one more tweak to the already working prototype.
A culture that projects a limited idea of kinds of people that might make good engineers needlessly turns away good engineers who don't fit the mold. You also risk creating a monoculture that will never even think of the best designs.
As people have already said, this is old news.
But, for people who care, here is the list of Darwin source packages are available for both x86 and ppc (as of OS X 10.4.6):
and here is the list of x86-only source packages
and here is the list of ppc-only source packages
A lot of the comments here seem to say something along the lines of
The mistake is to not realizing that in bad writing, the understanding part is not effortless. You waste your readers' time. If it costs each of your readers just two seconds more to read your badly written prose, how many readers do you need before the waste of their time outweighs what you see as a waste of yours. Precious few! If it takes you a minute to correct your grammer, fix that typo, or add an actual link to the website you've just mentioned, you may have saved tens of minutes of everyone else's time.
And you'll save us all wasting yet more minutes wading through responses to your post that merely complain about your grammer, post the missing links, and generally complain about or fix the things you were too lazy to do.
(Same applies to email, where too many people love emailing everyone a "memo" in the form of an attached a .doc file, saving themselves all of a second's worth of copy and paste...)
In my office, across from my new 2GHz dual G5, I have a 1991 NeXT Workstation. Admittedly, I don't have it on all the time anymore, but I do turn it on once in a while to convert old WriteNow files and such. (Until July 2001 it was my main machine and in use daily -- I had to wait until OS X before there were machines up to the task of replacing it.)
:-)
These days, one of my favorite uses of the machine is doing a side-by-side comparison with OS X. I compare the supplied Terminal, TextEdit and Mail applications on OS X and NeXTSTEP, showing that they're essentially the same programs, including details like the Font Panel and Color Picker. I then run OmniGraffle (2.0) on the Mac and Diagram.app on the NeXT -- again the two are essentially the same (OmniGraffle began as a Diagram clone and will read Diagram files). Finally, I run Abscissa (a graph-drawing program) on both and open the same file and show that it's exactly the same third-party app, just recompiled. Along the way I show things like live window dragging. It's pretty easy to see how OS X is in large part a continuation of NeXTSTEP.
The NeXT is, of course, a little slower, but people tend to be surprised when I reveal that the NeXT has a 25MHz CPU, whereas the G5 has two 2000MHz CPUs (factor of 160 difference), the NeXT is maxed out at 32MB of RAM, whereas my G5 is only at 3/16ths capacity at 1536MB (48x more), and the NeXT has a 1GB internal drive whereas the G5 has a 160GB drive (another factor of 160). The NeXT is more than twelve years old and nevertheless holds its own pretty well -- it certainly doesn't seem like 1/160th of the machine my G5 is.
Sadly, these days it takes a couple of tries before the internal 1GB hard drive spins up, and so I think one day it's going to go to that place in the sky that disk drives go to. That'll be a sad day, but not one I can't recover from -- at only 1GB, it's not like it takes much space to store a backup.
But wait, there are more errors
In my opinion, IOKit is what makes Darwin special. The way it uses inheritance and its concepts of drivers having different interrelationships on different `planes' (e.g., power, USB topology, code dependencies, etc.) make it easier to write drivers and support things like dynamic device attachment and power management that Linux still struggles with.
The Mac OS X's malloc library has built-in support for providing good leak detection. The command line tool leaks (installed with the free developer tools). Although leaks can be run on any program, it works best when you set the enviromment variable MallocStackLogging, which causes the system to provide complete stack frame information about when each piece of leaking memory was allocated.
Also of interest are the malloc_history and heap command-line tools. They tell you lots of interesting information about exactly what is on the heap and how it got there. The malloc library also detects double frees by default (making it immune to the recent zlib security vulnerability) and can also detect writing on free blocks, etc. Very nice.
Finally there is a graphical application, MallocDebug which provides similar information on memory leaks and memory use but also provides an easy to use memory-browser interface. Unlike simple leak detectors, you can explore your program's memory space and discover memory that isn't strictly "forgotten" by your program (it still has valid references to it) but should perhaps have been deleted anyway (e.g., finding memory allocated for a splash screen graphic). This last application requires that the code use a special library, but it is easy enough to make dynamically-linked programs use this library (thanks to Darwin's equivalent of LD_PRELOAD, DYLD_INSERT_LIBRARIES).
Although you can debug any code with these tools (from command-line tool to X-windows, Carbon or Cocoa app), they really shine debugging Objective-C, because Objective-C provides enough runtime information for the tools to tell you lots about the objects that are sitting there on the heap.
Here's Apple's announcement of their changes to the APSL. It has a few more details of what has changed.
From: Ron Dumont <rond@apple.com>To: publicsource-announce@lists.apple.com
Subject: Apple Public Source License version 1.2
Date: Thu, 4 Jan 2001 16:26:17 -0800
Message-Id: <200101050026.QAA18128@scv2.apple.com>
Hello,
We are pleased to announce version 1.2 of the Apple Public Source License.
We made several changes to better serve and protect the community that
has evolved around Darwin and other Apple Open Source projects. The
major changes are:
* You no longer need to distribute modifications made for personal use
(sections 1.4 & 1.8)
* You are no longer required to notify Apple when you deploy modifications
(previous section 2.2(c) deleted) -- though the notification site
will remain for those who want to use it.
* The Infringement / Suspension clause (previous section 9.1) has been
removed; you are now responsible for securing all necessary rights
yourself (section 2.3)
* Many of the license terms have been rewritten to also protect
Contributors, e.g., section 10 (the Trademark protection clause)
now covers trademarks and tradenames of any Contributor as well as
those of Apple.
We've also made numerous other changes to streamline and clarify the
license, so we encourage you to read it yourself at
http://www.opensource.apple.com/apsl/. We welcome your comments at
opensource-admin@group.apple.com. You are also invited to discuss the
APSL on the Open Source Initiative's license-discuss list. To subscribe,
send an email to license-discuss-subscribe@opensource.org.
We would like to thank the people outside Apple who helped us improve
the APSL to better serve the community.
Yours truly,
The Apple Open Source Team
The upside is that RedHat's gcc snapshot generates better code, thanks to the powerful new optimizations it contains. It also fixes some bugs in 2.95.x and works much, much better on RISC platforms. Hardly surprising given that it contains about a year's worth of development effort over gcc 2.95.x.
It's all very well for the gcc steering committee to take the attitude that gcc 3.0 will be done when it's done, but for those of us who want both a working compiler and one that has (almost) all the latest enhancements, RedHat's QA'd gcc snapshot is an absolute boon.
Lossy compression schemes such as Ogg Vorbis and MP3 work by removing sound that humans cannot perceive from the sound sample to improve the compression ratio.
Watermarking, on the other hand, adds sound information that human listeners supposedly will not be able to notice, but which machines will be able to detect. (And be able to perform this detection on any recording without being able to compare the watermarked stream against the original.)
These goals are in conflict. The only way that watermarks can be sure that compression technologies (including future ones) won't remove an inaudible watermark (on the basis that it won't be missed by the listener) is to design a process that uses an audible watermark. Thus, some people (hi-fi buffs, sound engineers, etc.) will be able to hear the difference between a watermarked and unwatermarked recording.
And, of course, most people will think they can hear the difference, and be unwilling to buy SDMI music.
The Hurd uses a Mach microkernel. Darwin uses Mach, but not as a microkernel (just like NEXTSTEP and OpenStep before it). Go read about it.
If it were just FreeBSD on Mach, you might have a point, but it isn't. Take a look at how drivers are written using IOKit, dyld, netinfo, the vm subsystem, the unified buffer cache, etc. for just a few of the many differences.
Mach is ``notoriously slow'' when core functionality is implemented as user-space servers. Performance is why Darwin puts this core code in kernel space.
Darwin is still in its earliest stages on x86. If you miss the early days of Linux and *BSD, you might enjoy helping get Darwin going.
If you want to try Darwin for yourself, you'll need
Once you have that hardware, you need to download two images: one for a partition of type AB (20 KB compressed) and one for a partition of type A8 (about 100 MB compressed). Create appropriately sized partitions on your disk (945 blocks and 920304 blocks respectively), and uncompress the images onto those partitions (I used primary partitions; extended partitions might work, too) and try to boot. You can either use lilo, or download a Darwin boot sector.
If you can boot Darwin, then you can begin to explore. If you like to hack on a new OS, or would like to see how Apple's idea of Mach (monolithic kernel) differs from that of the Hurd (microkernel), or even if you'd just like to see things done a different way (e.g., dyld vs. ld.so, netinfo vs. NIS, IOKit vs. ????, etc.), Darwin can be pretty interesting.
For more information on on Darwin, check out Darwinfo or Apple's darwin-devel mailing list.
Want caffeine with without all that other baggage (sugar, color, etc.)? Want to make your own custom drinks with caffeine (e.g., caffeinated orange juice from frozen concentrate)?
Well, a while back I discovered Water Joe. Each 17oz bottle has 60mg of caffeine (and they now do larger bottles too). It's a bit more expensive than cola, but hey...
The same company also makes other bottled water conconctions.
All hardware supported in 3.3.6 is also supported in 4.0.1.
All hardware supported in 3.3.6 is also supported in 4.0.1.
The AP6422 is supported in 3.3.6 but not fully in 4.0.1. The AT25 is supported in 4.0.1 but not in 3.3.6.
No ARK Logic chips are supported in 4.0.1.
All chips supported in 3.3.6 are supported in 4.0.1 except for Mach8 and some old Mach32 chips. The support in 4.0.1 is, however, unaccelerated for all chips except the Mach64, Rage and Rage 128 variants.
No Avance Logic chips are supported in 4.0.1.
All chips supported in 3.3.6 are also supported in 4.0.1.
The following chips are supported in 3.3.6 but not in 4.0.1: 6410, 6412, 6420, 6440, 5420, 5422, 5424, 5426, 5428, 5429, 6205, 6215, 6225, 6235, 7541, 7542, 7543, 7548, 7555 and 7556.
No Compaq AVGA support in 4.0.1. DEC TGA support is equivalent in both versions.
No Cyrix chips are well-supported in 4.0.1.
No Epson chips are supported in 4.0.1.
No Genoa chips are supported in 4.0.1.
The standard VGA core is supported in both versions, but there is no support for the 8514/A or XGA-2 in 4.0.1.
No IIT chips are supported in 4.0.1.
The i740 and i810 are supported in both versions, but the i810 is only supported on Linux/x86 platforms at present.
All chips supported in 3.3.6 are also supported in 4.0.1.
No MX (???) chips are supported in 4.0.1.
No NCR chips are supported in 4.0.1.
All chips supported in 3.3.6 are also supported in 4.0.1.
All chipsets supported in 3.3.6 except the NV1 are also supported in 4.0.1.
No Number Nine chips are supported in 4.0.1.
No Oak chips are supported in 4.0.1.
No Paradise/Western Digital chips are supported in 4.0.1.
No RealTek chips are supported in 4.0.1.
All chips supported in 3.3.6 are also supported in 4.0.1.
Only the ViRGE and Trio3D chipsets are supported in 4.0.1. All of the other chipsets are only supported in 3.3.6.
Support for the 86C201, 86C202, 86C215, 86C225, 5597 and 5598 is currently only available in 3.3.6.
No SMI chips are supported in 4.0.1, but the fbdev driver is reported to work on Linux.
The following (older) chipsets that are supported in 3.3.6 are not supported in 4.0.1: TVGA8200LX, TVGA8800CS, TVGA8900B, TVGA8900C, TVGA8900CL, TVGA9000, TVGA9000i, TVGA9100B, TVGA9200CXr, TGUI9400CXi, TGUI9420, TGUI9430DGi.
All cards supported by 3.3.6 are also supported by 4.0.1 except for the old ET3000.
No Video 7 chips are supported in 4.0.1.
No Weitek chips are supported in 4.0.1.
Do you have any suggestions for a better way?
I prefer snort. It logs attack attempts, but doesn't do the blocking that PortSentry does. Snort is very configurable, and can log a good deal of information.
The question I have (which I've been thinking of submitting to Ask Slashdot) is what to do with the lists of attacker IP addresses. I'm sure these are mostly just ``innocent'' compromised hosts, but it would be nice if there were some organized way for us to keep track of who those hosts were, so that people who were concerned about security could blacklist them.
Of course, there would need to be a way to ensure that the reported IP addresses are genuinely attackers (otherwise script kiddies could just submit claims that you were hacking them). Maybe Advogato's method for establishing a trust network could be adapted to the problem?
Typically, I run
find . -name '*.eps' -print | linksame
to be sure the links it wants to make are sane, then
find . -name '*.eps' -print | linksame | sh
to actually do the linking.
Anyway, for anyone who'd like to have this `innovation' on their machine, here's the script:
#!/usr/local/bin/perl -w
use strict;
my %sizes;
while (<>) {
chomp;
my $size = (lstat $_)[7];
++$sizes{$size}{$_} if (-f _ and $size > 0);
}
while (my ($size, $filehash) = each %sizes) {
my @files = keys %$filehash;
next if @files < 2;
my %sums;
foreach my $file (@files) {
$file =~ s/([\s\\<>&;\{\}\[\]\(\)])/\\$1/g; # Quote shell metachars
(my $sum, undef) = split ' ', `md5sum $file`, 2;
warn "Couldn't sum $file\n" unless length $sum == 32;
push(@{$sums{$sum}}, $file);
}
while (my ($hash, $same) = each %sums) {
next if @$same < 2;
my $first = shift @$same;
print "chmod ugo-w $first\n";
foreach my $other (@$same) {
if (system("cmp", $first, $other) != 0) {
warn "files $first and $other look the same but aren't\n";
next;
}
print "ln $first $other\n";
}
print "\n";
}
}
For those who want to know what is actually new in Perl 5.6, you want to look at perldelta . (The message linked to above is just what was new since the last beta).
It's a mistake to conclude that once you have something that looks like NEXTSTEP (or some other OS), you will have something that is like NEXTSTEP (or some other OS).
Sure, it's lots of fun to play with The Gimp and make some skins. But there are plenty of things beneath the surface that aren't glamorous but have a huge impact on usability. The imaging models that are integrated into NEXTSTEP and Mac OS X make a huge difference for developers, making it easy to develop applications that can produce high quality printed output as well as excellent screen output. Similarly, having a pasteboard that can handle images, mail messages, line art, and so on -- seamlessly -- makes life easier for users and developers alike.
Most people who think it's easy to imitate NEXTSTEP have never actually used the system for any length of time, and have never taken a look at the `under the hood' complexities the GNUStep project is tackling in their attempt to bring some of the underlying functionality of NEXTSTEP to other OSs.
Finally, just because the concepts embodied in NEXTSTEP (like its imaging model) are several years old doesn't make them outdated, irrelevant, or easily imitated today. On my desk I have two machines: a cool dual processor PC running RedHat 6.1, and a 25Mhz NeXTstation that's about nine years old. I do most of my work sitting at the NeXTstation. I think that speaks volumes.
Mneme.
As I understand it, Linux's memory subsystem has seen a major overhaul in 2.3 to correct some early design flaws.
Some people seem to think Linux still has design flaws. (I see people in the BSD and fledgeling Darwin communities claim that their kernels are have a better architecture than Linux, although I rarely see much substantiation of these claims.)
So, are these people zealots, too deeply invested in their operating systems to face the truth that Linux is at least as good, architecturally; or were they right once, but the architecture problems have been resolved in 2.3; or are there still architectural weaknesses in Linux 2.3.
If so, what are these weaknesses and how serious are they? And how would you answer if we were comparing Linux's architecture to that of a commercial OS like Solaris.
So, basically, as you look at Linux, do you see parts of the code where you think `If we had it to do over again, we'd never do it like *that*'. And do you think Linux is any worse than other operating systems in that regard.