Slashdot Mirror

Tanya is Chris Lattner's wife and a longtime software developer at Apple
http://nondot.org/tonic/Welcom...

Sounds like they're looking for Chris Lattner.

Why does Apple use LLVM? 1. They hired Chris Lattner

Did Apple hire Lattner because they wanted to use LLVM?

Sorry for bad netiquette. Also interesting ...

* LLVM The Early Days
http://www.nondot.org/sabre/20...

Why does Apple use LLVM?
1. They hired Chris Lattner
2. LLVM has a more modern back-end (better suited to leverage high level optimization techniques across architectures, say x86, x86-64, PowerPC, Arm)

Of course copyright reassignment (or release to the public domain) is required for GCC contributions, LLVM only requires that copyright holder to agree to release the code under the terms of the LLVM license. Tight integration of the XCODE developer tools might be problematic had Apple stuck with GCC.

Since your company is on the commitee, I'll take some time to bitch at you about JOGL :)

First, JOGL mirrors the C API too closely. Things that are necessary in C become down right absurd in Java. For example, the gl prefix on everything. This is necessary in C because it doesn't have a concept of packaging. Copying the C api into Java directly makes it worse since you usually invoke it on an object making it gl.glEnable(GL.GL_DEPTH_TEST); Every single line you write that calls into JOGL takes about 15% more typing for something that isn't even necessary and interferes with auto-complete features like those in Eclipse.

Secondly, the OpenGL suffixes are unnecessary (3f, 4d, 3i, etc.). C doesn't have function overloading. Java does. Java programmers think this is a good thing. Use it.

Third, Java just added type-safe enums. Use them. The OpenGL interface is very type-unsafe. You end up passing in a lot of int flags. And there are lots of int flags with subtle different meanings. Although, JOGL has excellent error detection facilities, there is something to be said for prevention also.

But those grips aside. JOGL really needs to ship as a standard part of the java platform. I mean, I have JOGL applets sitting on my website that no one in their right-mind is going to view. I can't automatically install the java classes that they need because they need native code on their platform to support it. And if you try to use Cg it is even worse. So, until a binding ships with a VM it is not done.

Thanks for the info about Xith3D. I'll have to give it a more thorough look.

(Unfortunately the site seems to be slashdotted so I can't see what Linus actually said. Roll on Freenet.)

The SCO complaint is written in plain English; you don't need to be a lawyer to understand it.

Their heart of their complaint is in paragraph 85: "It is not possible for Linux to rapidly reach UNIX performance standards for complete enterprise functionality without the misappropriation of UNIX code, methods or concepts to achieve such performance, ..."

SCO consider themselves to have some kind of godlike power to write enterprise operating systems, that could never be matched by anybody else.

This is clearly incredibly silly. Linus is well qualified to demonstrate that the improvements in Linux have come about through independent work or public documentation, and from many contributors only a few of whom are at IBM. It's also clear that performance has been steadily improving over the last 12-odd years. There's no sudden dumping of SCO IP into Linux.

Things that have been borrowed from proprietary Unixes have been taken from public documentation or whitepapers. The slab allocator is a case in point.

In fact, you don't have to be Linus to work this out for yourself: just look at the lkml archives, and observe how many patches have been sent by non-IBM hackers. The development process by which Linux's performance was improved is largely a matter of public record.

-Chris

In general, the Itanium has seen quite poor adoption rates and even Intel/HP admit that their initial public silicon is really only fit for software developers and platform work (due to low performance, and altready established players in the 64-bit field).

Do you think that IPF64 line will see any kind of broad industry adoption? Will it become just like rest of the (non-embedded) processor architectures designed since the x86 -- constantly fighting for 5% of the market? Do you think the AMD Hammer architecture will be a meaningful player in the field?

Since your group is a key player in the Linux on IA64 and GCC for IA64 projects, can you give us any status information about recent developments in the project since the IA-64 Summit?

Thanks,

-Chris

-Chris

Well, looks like this guy Chuq is working on it. He seems to be a kernal hacker that works for VERITAS.

You can also find interesting filesystem info here

There's also work being done on TRAM (Transactional RAM).

Thanks for answering your own question. It has nothing to do with their choice of language... it has to do with how they choose to use the OS.

-Chris

Yes, perhaps, but you have to realize that G++ is portable to just about every single platform that GCC is... and that is a lot of them. The new G++ has an excellent C++ front end that is quite standard comformant.

One question though, is what platforms are you really winning by using C on? If there isn't a C++ compiler for the platform, are you really that interested in using a big groupware application on it? (assuming it's an older platform)...

-Chris

One very important thing to remember about code size is that LOC is a very good indicator of # of bugs. Reducing the number of lines of code (obviously without reducing functionality) is a good way to reduce # of bugs, and also to make your hackers more productive.

There are many higher level languages available, in many different language families. Often high level languages get blasted for being in efficient... but this isn't neccesarily so. For example, with all of the "object" stuff implemented (the hard way) in C, you are paying exactly the same runtime overhead that C++ pays when it has an object. All you are gaining, is the joy of having to implement everything yourself and the possibility of your naming schemes getting out of whack.

I think it's great that Ximian is continuing to survive and is about to "unleash" their masterpiece onto the world. I just wonder how much faster it could have gotten here if they didn't use C.

I find it interesting that the open source community (for the most part), tends to stick with C as the language of choice. Lowest common denominator choices like this are usually not the best.

-Chris

From the perspective of a KDE developer (the primary users of QT fwik), I really have to wonder how much of this stuff is desirable:

"Database Programming: Qt 3.0 will include a platform- and database-independent API for accessing SQL databases": KDE already has put significant resources towards a uniform Database model, as has the GNOME project and even specific languages (DBI for perl, f.e.). Why do we need or want, yet another splinter in the market?

"Qt Designer: Qt Designer has now evolved from a dialog editor to a true GUI builder.": Okay, so they seem to have cloned some of the capabilities of KDevelop and others. My question is WHY? So they can sell it to windows users?

"Qt Assistant: Qt 3.0 features a separate application called Qt Assistant, which can be used to browse the Qt Class Documentation, as well as the Qt Designer and the Qt Linguist manuals. Qt Assistant offers index search, contents overview, bookmarks, history and search in pages. ": Again, KDevelop seems to have most if not all of this capability...

"International Text Display": Hrm... pango in a box.

"HTTP network protocol support": Proving the QT is not just a gui toolkit, they implement protocol support. What the heck for? Isn't this better implemented in the 'framework' kind of level as KDE has done? Konq obviously supports this, as does the protocol facilities in general...

"New Component model: Qt 3.0 will provide a platform-independent API for runtime loading of shared libraries and accessing of their functionality using a COM-like interface concept": WHY does QT want to develop their OWN object model? Isn't enough enough? Do they really have value add here? XPCOM is MUCH more portable than they could ever support QT with. Why would they want to add this?

Being a naive user, I have to wonder how much of this is actually useful for free software development. We seem to already have superior solutions for much of what they are providing. Some things (that I have not listed) will definately be nice (64bit portability, better unicode/localization, multiscreening, etc...) and actually seemed to be related to the core of QT: the graphics toolkit.

It seems to me that they are basically trying to reinvent what the freesoftware community has already developed in order to sell it to those less worthy (ie win32/commercial developers). Am I missing something here, or is there a reason a GUI toolkit should have its own incompatible object model?

-Chris

1. Classes
2. Class Members
3. Strings
4. Collections
5. Hash tables
   ...
6. Memory Management
   ...

I can see it now: "our language is so technologically advanced that you can use STRINGS if you become an expert in it." and "yeah well sure perl has nice hash's that they tell you about in the first chapter of learning perl. You can read about it on page 99 of the advanced features guide!"

-Chris

Performance: SDL does take advantage of hardware accelleration where it can (ie bitblts), but it is limited by the OS/environment it is running on. My impression is that windows device drivers, for example, do a much better job of this, than say, FBDEV.

Maturity: SDL is a relatively new library, and although it has been used in some large projects (by real companies [loki]), it still has a ways to go. Of course, this is where SDL is also making its greatest strides.

Industry support: This is the killer. The break or be broken issue. Direct* is well supported by all kinds of hardware devices (not just video, also sound and input devices). Until we can get really good support from the industry behind SDL, it will be lacking in comparison.

The one wonderful thing that is quite uncommon in the free software world is that there seems to be one defacto standard for games programming (SDL obviously). Although there are MANY MANY alternatives (having written a few myself), it is VERY good to have a standard that people/companies can rally around. (/me tries to avoid bringing up KDE/gnome foolishness :)

So anyways, yes, SDL is a good thing. Who knows, maybe Linux (and the other platforms SDL supports) will start getting more games out on them as primary platforms some day?

-Chris

1. Are mostly posix
2. Are mostly gnu
3. Are mostly free (by some definition of free)
4. Are mostly X based

I bet if you were really whacko you could set up a freebsd box that was indistinguishable (in terms of user experience... installed packages, file system layout, etc) from a run of the mill Linux box.

So I guess the real question is: is linux a desktop OS yet?

-Chris

Game developers.

In 18-24 months, the GF3 level of "computing" performance will be more accessible and commonplace. Incidently this is about the amount of time it takes to build a game... and developers like to be able to debug on REAL hardware. :)

-Chris

Actually by making it pretty easy to put "flashy" effects in, this card might allow the developer to spend more time working on the other parts of the game.

Perhaps, but not likely. Almost every effect is a special case hack that is designed to look good, at the expense of generality. This means that the engines for games (Quake 2/3 is a perfect example) become very specialized. If you want to base a second game off of the same engine, you get exactly the same set of effects as before, because the design is not very extensible.

My reference to simpler games of yesteryear goes farther though... try to get a group of people together for a netparty, for example... how many people do you think will be able to run stuff that requires a Geforce 1, much less a brand new Geforce 3? Second quesion is: why would you want to?

It seems like the technology trend is to push the envelope to the next step (GF3 is a logical progression from GF2), and then software has to play catchup (no, not ketchup :). It seems that, especially with the first few games for a technology, games focus on doing things because they "can", not because they "should".

Instead of designing games with a clear focus, plot, and motivation, games tend to get dilluted to being flashy silly things. Sure they look cool and have nifty features, but are they really FUN to play? Where is the replay value and interactivity with other human players?

The problem with, for example, vertex shaders and the other DX8 features is that they are not a simple extension of a uniform graphics architecture.

Instead of being able to designing a simple graphics engine that supports a variety of features, and then enhancing it as the game progresses, they have to "Target" a "technology" (for example DX7 or DX8). Of course, they two are essentially completely different APIs, and they are mutually exclusive. This means that you get to rewrite your engine every time you want to support a new "technology".

In a lot of ways, I'm really happy that cards (specifically the radeon and GF3) are moving towards programmability and higher quality visuals. It's quite a different race than pushing fillrates and making up stats on textured poly's a second. Maybe when things are fully generalized, we won't NEED an API like DX that gets constantly mutated, torturing developers...

Oh wait, that's called OpenGL. (sorry, couldn't help it. ;)

-Chris

While it may be that the PowerVR2 did not implement it correctly, there is nothing that prevents performance much better than immediate mode style rasterizers. Consider it this way:

A game needs to draw 5 opaque polygons, with 3 alpha polygons on top.

An immediate mode rasterizer would have to write all five polygons to memory, including all of the associated texture lookups and lighting calculations. Then, for each alpha polygon, it would have to reread bits from the framebuffer and combine it with the shaded textured alpha polygon. This is a lot of memory traffic.

A tile based renderer, otoh, would not need to do all of this. Obviously it would be able to eliminate all of the overdraw on the opaque polygons, but it would also be able to do the blending in the ON CHIP 24bit tile framebuffer, which is much much much faster than going to off chip memory. This means that instead of having to do read-modify-write off chip memory cycles for each of those alpha blended polygons, it stays on chip.

Now like I said before, I am not familiar with the PowerVR2 chip, and it may be that they do not implement this obvious optimization... I would assume their newer chip would.

My big question is "why not a T&L unit?" It seems like a sever handicap to an otherwise stellar chip. Although somewhat addressed in the article, they didn't really justify it well, and the benchmarks prove it would be handy. Maybe the 175mhz clock is what prevents an effective T&L unit from being added...

-Chris

I agree. I never understood why my grandma couldn't figure out how to just flip 32 switches into the right position and hit the "store" button like everyone else... I had to get rid of my poor PDP just 'cause she wanted something pointy and clicky...

*sniff*

-Chris

Has anyone else heard anything more about this, or has Transmeta stopped pushing this? Wouldn't it be nice to have a 4 way transmeta in a half U space? :)

-Chris

http://kt.linuxcare.com/kernel-traffic/kt20010108_ 101.epl#7, http://kt.linuxcare.com/kernel-traffic/kt20001127_ 95.epl#6

and especially: http://kt.linuxcare.com/kernel-traffic/kt20001002_ 87.epl#3, http://kt.linuxcare.com/kernel-traffic/kt20001010_ 88.epl#7.

Have a good read. KernelTraffic Rocks.

-Chris

http://www.nondot.org/~sabre/os/

For the last 4-5 years or so it has served as a nice repository for documentation on all aspects of OS design, and even hosts open hardware specs. In OS design circles it is pretty widely recommended. I look forward to being able to work with the OpenH people: we seem to overlap on a lot of our goals.

Anyways, I hope that this site is useful to our whole community! :) When the OpenH site is unslashdotted, I look forward to seeing what they have available!

-Chris

If the API is any indication, I can only imagine what the implementation is like. Actually, I was looking at the bootloader code for Win95 the other day. Some guy had dissasembled it, and he kept refering to the code's author as "some crazy mother f*cker." Take a look here. A couple of the comments are hilarious (as is the code!)

Okay, here's another example: http://korbit.sourceforge.net. (disclaimer, I'm a lead developer on the proj).

I'm trying to point out that innovation in neccesary for Linux to not become stagnant. Just like you said, we don't want to copy windows. We want to take the small subset of GOOD ideas from windows and run with them.

I think that linux is doing an awesome job in the realm of simple web/dns/file servers... but that can also be done by a set top box. Lets try doing something interesting, and lets push the envelope a little bit.

A lot of very interesting projects get killed way before their time because they are preceived as being too slow. Hell, with an expodential increase in computing power, do we really need to care about each clock cycle anymore? Isn't it more useful to concentrate on getting INTERESTING things done pretty well, then something BORING done way too well?

Sure sure, you can optimize things all you want, and in many cases optimization is a very good thing. Optimization, however, is best done by computers: for example the compiler level, or done at a very high (Design) level by people. Microoptimizing every detail of a system is not only silly, but it is broken.

Scratching the itch is definately what drives the linux community, but it is also what holds it back in some way. Being driven to fix particular incarnations of problems in software is a wonderful way to limit your thinking to what is "inside of the box". We need people to think outside of "what is accepted" and we need people to listen to them when they do.

I know that I have some fairly excentric views here, but they should be voiced.

Maybe I'm just getting senile in my old age. ;)

-Chris
http://www.nondot.org/~sabre

Actually, its not just like that, it is that.

A good introduction to the field: A 1996 paper on Secure Deletion of Data from Magnetic and Solid-State Memory.

Be warned that this paper was dated 1996. Technology has improved significantly since then. The state of the art in magnetic force microscopy and magnetic force scanning tunnelling microscopy is almost certainly highly classified.

Your audio analogy is excellent. In the case of your cassette tape, it's a virtual certainty that the record head was "off" by a fraction of an inch when it recorded the white noise over your Metallica. (And it went "off" by a different fraction of an inch when you recorded the clear signal on top of it).

So, a forensics dude will use tools to read the fraction of an inch that didn't get overwritten by the white noise, and the other fraction of an inch that escaped the clear tone, and reconstruct most of the Metallica song.

The same thing works with hard drives, except it's a hell of a lot more work.

That having been said, this technology is at the bleeding edge and costs a fortune. It's probably only used in to recover data of interest to national security.

Your typical criminal is st00pid, and your typical FBI goon merely looks at unallocated blocks containing data the criminal thought was erased.

A smart FBI goon will also use a tool to read sectors that have been marked as "bad" - there may be data there that the

A good data shredder, incidentally, will take into account the model of the hard drive and the encoding method used by the firmware - when you write "FF" to a drive, you're not actually writing eight "north poles" in sequence - and write a sequence of bytes geared to "even out" the magnetic flux as much as possible.

That said, even this isn't bulletproof. The last time I looked, the only acceptable standard in the military (and presumably in the intelligence community) for scrubbing highly sensitive data is physical destruction of the media.

If it's your nudie pics or your company's secrets, encrypt the volume or scrub the data when you're done with it. Better yet, do both.

If it's plans for compact nuclear warheads and you want to sell them to the Chinese government, make sure your friends give lots of money to the Democrats. Uh. I meant, "physically destroy the media after you've made the sale".

As long as the media is intact, if the data's important enough, someone will be able to recover it.