[describing his own various research interests...]
Role of p53 in Cancer
Our p53 studies are focused on the mechanism and role of this TSG in how normal tissues respond to genotoxic stresses associated with cancer treatment. Our previous studies have shown tissue specificity of p53-mediated apoptosis and its major role in determining the radiation sensitivity of mammals. We defined p53 as a determinant of cancer treatment side effects; the new therapeutic conceptâ"targeting p53 for therapeutic suppressionâ"was justified by isolating a small molecule p53 inhibitor that rescues mice from lethal doses of gamma irradiation.
Analysis of an animal model of chemotherapy-induced hair loss (alopecia) has indicated that p53 plays a major role in this common side effect, thus opening another area for clinical application of p53 inhibitors.
Mechanisms of tissue specificity of the p53 response are being addressed by cDNA microarray-based analysis of tissue-specific p53 responsive genes. This direction of studies is linked to identification of new tumor markers among the genes that are under the negative control of p53, a mechanism we have shown to be a possible underlying cause of elevated prostate-specific antigen expression.
The role of p53-dependent apoptosis and growth arrest and the interaction of p53 with other signaling pathways (TNF, Fas, heat shock, etc.) in determining its tumor suppressor function is being analyzed in several model systems. The impact of distinct p53 function (i.e., control of growth arrest or apoptosis) in its tumor suppressor activity is under investigation. We showed that control of radiosensitivity of tissues by p53 in vivo does not involve the p21/waf1 p53-responsive CDK inhibitor. Induction of apoptosis was found to be dispensable for p53-mediated control of genomic stability; moreover, suppression of p53-dependent apoptosis by Bcl-2 delays tumor progression by eliminating selective advantages for genetically unstable p53-deficient cells.
Having already defined ING1, Bloom syndrome and SUMO proteins as p53 interactors, we are continuing the search for cellular modulators of p53 expression and function among p53-interacting proteins; several additional candidates are under study.
Drug Discovery Program
Our drug discovery program involves searching for new p53 inhibitors and testing their potential therapeutic applications for reducing cancer treatment side effects and possibly other pathologies involving p53-inducing stresses. It is based on creation of new cell-based readout systems and high-throughput screening of chemicals with the desired biological properties.
We are also isolating a new class of small molecules acting as modulators of multi-drug transporters that can greatly change the pattern of cross-resistance, including the ability to enhance their activity against certain compounds. The molecular mechanisms of activity of newly isolated compounds are being addressed, as are therapeutic fields for their practical applications.
Collaborators:
Elena Feinstein, M.D., Ph.D. (Quark Biotech, Inc., Nes Ziona, Israel)
Peter Chumakov, MD, Ph.D. (Lerner Research Institute, CCF)
Michelle Haber, Ph.D. & Murray Norris, Ph.D. (Children's Cancer Institute of Australia, Sydney)
Raymond Tubbs, MD (Pathology, CCF)
Mikhail Nikiforov, Ph.D. (University of Michigan)
Mark Whitnall, Ph.D. (Armed Forces Radiobiology Research Institute)
Boris Naroditsky, Ph.D. (Gamaleya Institute of Microbiology, Russia)
Bruce Blazar, MD (University of Minnesota)
Joseph DiDonato, Ph.D. (Lerner Research Institute, CCF)
George R. Stark, Ph.D. (Lerner Research Institute, CCF)
>The discussion topic was about the nature of ethics. What are they, where >do they come from, etc. One of the things that came out in class was that >the majority of people in the class thought that ethical behavior came >from God. If you were an Athiest, you could not be ethical.
For all the fact the libtool tag line is "Do you really want to worry about linking on AIX yourself?"...
I spent quite a bit of time this summer trying to use autoconf'd stuff on AIX (Gtk+). I played with a pile of recent and not-so-recent versions of libtool. It was a pain in the butt. (Granted, linking on AIX is... abnormal... but you'd think libtool would know how to do it).
I think the power of the autoconf suite to make things work across "all Unices" is a bit exaggerated. Check whether it really does a good job of supporting all the platforms you need, first.
Just to play devil's advocate here for a minute -- if we're only ever allowed to implement what the standard dictates, how will we ever come up with anything new?
I mean, sure, you can sit down and write a totally new scripting language.
And no one will use it.
All computer systems change evolutionarily. C has evolved within itself quite a bit. C++ is a superset of C, with some caveats. Java is a language whose syntax inherits a lot from the C family, but is quite different.
Linux is like many other previous Unixes, except... that it's an evolution, and is different.
It causes problems. It makes life difficult (everyone who's programmed Unix-like OSs knows that's a pain in the butt).
But are you seriously going to argue that we should have stuck to the one official narrow definition enshrined by ATT in the early 80s, and that no new implementation should differ in the least?
...
I would argue that "Embrace and extend" refers to, specifically, "Embrace and extend with non-standard, non-free additions that lock customers into our products and only our products, forever".
Anyone is free to make ksh or ash (or whatever) have a bash bug-compatibility mode to make people's lives easier in porting scripts. Hell, the Linux kernel has bug-compatible syscalls.
I apologize if my tone comes off confrontatively:-).
I'm reacting negatively to the idiotic suggestion that people need to waste time "writing a real Bourne shell for Linux".
If you don't like bash, there are several other shells which attempt to be POSIX. Some of them are quite strict (ash). Some are optimized for scripting (ksh).
If you want to argue that bash sucks and should be replaced as the default system scripting shell, I totally agree. If you want to say that it sucks when scripts request/bin/sh but use bash-specific features, I agree.
But for goodness sake, give some respect to the work that's been done.
...
I did see one good post noting the bash specifics that are missing, as a POSIX shell. They really are quite minor...
If he's going to complain about bash being not exactly POSIX, he's got to show an example of an incompatibility (as a decent sometime bash and ksh hacker, I can't think of one -- and I can think of one subtlety that ksh and zsh do differently than POSIX: word splitting).
Ok. "export FOO=bar" doesn't work on a strictly-POSIX shell. But why is it bad for that to work in bash (and ksh and zsh)? How does that hurt you?
Instead, why doesn't the article's poster come up with an example of a valid POSIX statement that breaks in bash -- that way he actually has a complaint: he did something POSIX (i.e., the standard), and bash did the wrong thing. As it stands, he's just griping.
I mean, I agree with him -- bash is bloated and not a good choice for scripting. But that just means that scripts should be written in a shell optimized for scripting -- ksh. Or at least a minimalist straightforward POSIX shell (ash).
But if a system wants to provide just one POSIX shell (to save space, or whatever), and if bash is going to be used by 95% of users anyhow (so is likely to be loaded anyhow), making the one POSIX shell available on the system be bash isn't a bad call. Now that doesn't excuse scripts using non-POSIX features under the name of/bin/sh. But I'd hazard to guess that 99% of the time those scripts are distro-specific in many other ways, so it doesn't really matter.
I still have yet to see how (from anything but an efficiency perspective), this guy is finding that bash somehow makes his life harder.
(side-point: it is annoying that you can't solve the efficiency problem by relinking/bin/sh to ksh or ash, since all the system scripts will do slightly-non-POSIX things and therefore should be specifying/bin/bash).
...
I apologize for my confrontational tone. It really irks me when people propose writing things without bothering to check if the work has been done for them. I mean, come on, guys, it's Free Software. Avoiding duplication is the name of the game.
Ok. ksh and zsh are supersets of the POSIX shell. And I agree, strictly speaking it's bad to shebang/bin/sh and then commit travesties like "export FOO=bar".
But give me a break.
If you want to script, you have no excuse to be using anything other than ksh (or just maybe ash).
AIX comes with only ksh in the way of POSIX-shells.
Why do we have to live like there has been zero progress since the original POSIX shell spec? And who could be so brain-damaged as not to notice ksh, the unquestioned pinnacle of scripting shells, and zsh, the unquestioned epitome of user shells?
Gee whiz. Don't waste your time; go write something useful.
(....grumble, grumble, idiotic duplication of effort....)
The point about critical-section efficiency on MP systems is pretty key. I think that calls for a multithreaded, multiprocessing retest...
But in any case, if your application is spending a significant amount of time grinding on waits for mutex constructs (i.e. any of the syscalls discussed), you're having a bad day -- it means your threads are spending a lot of time in critical sections, and are going to spend a lot of time waiting for each other.
There are schools of concurrent design where you typically have threads blocked on a mutex waiting to move forward, but I don't think those are particularly high-performance models in the first place. Better to stick to the old dictum: "minimize the critical section", both in length and in frequency.
(caveat: I think microkernels are silly firewalls in code that should be correct and trusted)
There are going to be speed problems with any microkernel-based OS -- OS X is not necessarily exempt either.
Basically, if you spend a lot of time copying data between address spaces of different chunks of the kernel, you're going to pay for it. If you have to switch address spaces to switch kernel tasks, you're going to pay for it (in cache misses).
Even in a monolithic-kernel OS (which will always be superior, if you assume the parts of the kernel are well-enough written that they can be trusted by other parts of the kernel), you have some cost moving data from userspace to kernel space. You can get around that in clever cases -- Linux does this with zerocopy networking, passing sets of (physical) pages around and dumping them directly to the card driver.
As Linus once said "Mantra: `Everything is a stream of bytes'. Repeat until enlightened." In other words, any obsessiveness that gets in the way of moving streams of bytes around extremely efficiently is not good architecture. Message passing (and separate address spaces for kernel "server" modules) fall into this category.
1) "Competition has no other choice than to buy product from Baby Bell."
2) "Undercut the competition until it's gone, then raise prices."
Number 1 sounds like a monopoly to me.
Number 2 sounds like a monopoly violating anti-trust law.
Contact your Better Business Bureau. Find some smart lawyers who want to make a buck. Does anyone else think it's time for a class-action suit?
[Verizon just raised DSL prices in the Pittsburgh area too. I'm just lucky that CMU decided to raise their prices as well and keep running their private happy little DSL service for students & profs]
I mean, yeah, they're totally different. And they're faster clock-per-clock (with added benefit to FP stuff).
But a 1.4GHz Athlon blows away a 7-800MHz UltraII for most kinds of computation. A 1 GHz Athlon seems to be about (42, 29) on the (retired) SPECint95/SPECfp95. A 450Mhz Ultra-II (not Ultra-IIi, I'm looking at results for an SPARCstation Ultra-60) gets about (20, 27). That's a bit faster int clock-per-clock, and a lot faster FP. Note that for practical stuff (databases, web, whatever) int is more important. Of course benchmarks are hard to interpret, but this gives you an idea. All the SPEC benchmarks are available at www.specbench.org. Of course there are no Ultra-III results, but I'm guessing it's not going to be 2x as fast as the best x86s (at least I'll wait to see the results before I believe it).
You use a Sun because you want an architecture that will scale smoothly up to 64-way (I *guarantee* that will be faster than any single x86 machine).
Actually if you want to both go fast at the low end and scale well, you can buy an RS/6000 -- IBMs Power3 and Power4 chips are absurdly fast and scale very well (and actually focus on memory bandwidth for database performance). But a bottom-of-the-line Sun is a lot cheaper than the cheapest RS/6000.
Full disclosure: I work for IBM (in software) and I've seen a good bit of internal stuff about IBM chips, esp. the upcoming Power4. Most of that information has now been published in MicroProcessor Review and is now publicly available, I think you'll find it if you poke around...
(even more amusing full disclosure: I'm a huge fan of old Sun stuff, their machines are beautifully engineered. i use a couple old 32bit sparcs for all kinds of things)
Actually, Java is at a huge loss with its native libraries.
Languages like PERL and Python know they're natively slow, so they do all the real work underneath in C/C++ libs (that's how PERL's regexp's fly, and how Python-Numeric is within a small constant factor of number crunching in straight C).
But Java has some *terrible* langauge design choices that really limit speed:
- Everything is an Object. This means that you can't have typed containers (i.e. templates), so you have to do expensive dynamic-downcasts when you remove objects from the container (heh, in C you'd just say "I know it's a struct foo*!" and cast away happily".
- Except *not* everything is an object -- primitive types are second-class citizens, so to use the container library on ints or floats you have to use the heavy capital-I-Integer, etc
- All method calls are virtual. This is a small but insidious memory-lookup on every function call... (can be avoided in most places in C++, but is sometimes necessary).
...
If you really want to go fast, you use OCaML -- C and C++ are relatively speaking very hard languages to optimize. Strong typing (without Java's silly "strongly typed, then throw away the type info!") allows you to do much more rigourous analysis at compile time, so you have a much stronger picture of what the data flow graph is. For example, in C/C++ it's almost impossible to draw the data flow graph anywhere but in the basic block (think "within a set of {}") -- and even to do that the optimizer is making assumptions. In OCaML the data flow diagram contains the whole program, so the compiler can optimize across function calls.
...
Note to the lisp junkies: get over syntax. Someone should write a "straight abstract syntax tree" frontend to OCaML just to make you guys happy. Gee whiz.
Not to be an apologist for a software program I woiuldn't use in a million years, but...
Word 2000 runs *beautifully* on my mother's ancient Toshiba P120 laptop, with 48mb of ram. It was pretty slow with the evil continuous spelling/syntax checking on, but with that off, it starts almost as quickly as good old WordPerfect 6 (previous word processor, came out in about '93), and runs about as fast.
...
Of course the myths about Windows having a sane setup for program installation and system installation are.... less credible than the whole story about Odysseus (giant cyclops included).
I have *never* seen a better method for program installation than Ximian's RedCarpet, btw.
...
That said, speaking as a Linux programmer (several different Free projects: SashXB, VPython...):
"I don't give a damn whether anyone else finds Linux useful".
I use and hack Linux because it's what *I* want. I don't care if it beats any other operating system. If other people happen to find my stuff useful, fine. But I'm not going to adulterate it at the cost of user choice. When I do intro-to-Unix (primarily Solaris) classes for the CS freshmen at CMU, the point I stress is that TMTOWTDI.....
This is the meat of the matter. Dead on, you saved me an identical post:).
This is the impracticability that Bruce Schneier is talking about: if factoring is secure enough that it would take Eve a year (or 1000 years) to break an RSA-encoded message --- if you need to go from public-key to extremely strong stream/block cypher, you can use RSA to exchange a secret, then use Blum-Goldwasser squaring, which is as strong as factoring (if computationally expensive) --- then the assaulter is going to look for another weak link. For 99.99% of all crypto applications (and maybe it really is 100%), being secret for a good period of time (which you can adjust with key length) is as good as perfectly secret, forever.
OTP is certainly not new. And in fact it's only ever been governments who have the resources to put it into practice. Generating random numbers even at just enough rate to cover all your text is not cheap. No you can't use a cryptorandom number generator. Think about it, if it was an algorithmic generator, you could just give both parties copies of your unbreakable but deterministic generator -- they'd exchange the secret start value by RSA, or when Alice and Bob meet in a dark alley -- and you wouldn't need any satellites, or to generate pad at 10^6^6 numbers a second. I guess to generate pad that quickly, you'd need to do some quantum observation with a 50/50 split or something -- you certainly can't have monkeys up on your satellite rolling dice that quick (believe it or not, during WWII, RAND Corp. used to produce the OTP sheets, generated by people rolling dice).
So yeah. I'm not impressed with this guy.
Re:(somewhat OT) Technical Comment about GlassCode
on
Glasscode Released
·
· Score: 3
Bwahahahaahha!
Most of my posts make it to 5 (check my karma if you don't believe me). Especially considering how rarely I post to/., being marked a troll is beyond funny:)
Honestly, i don't see why an observation about the performance of GlassCode isn't a valid comment when the code itself is released.
Yes, I'm an anti-Java person. I think i'm a pretty well justified one, in general. I honestly have yet to see the Java system that performs as advertised. Now maybe GlassCode really is just under the weather and is usually better, but you'll forgive me. My last two anecdotal Java experiences were:
- Using the SameTime (IBM's message client, used a lot internally there) Java client on Linux. The beast took 90 megs of space (RSS). By contrast, the SashXB SameTime client (which my group wrote), took only 30 megs, and ran much more responsively (this was on GHz pIII's, running IBM's absolute-latest JITC-based JRE). And the SashXB version was written in JavaScript on top of Mozilla:)
- Using JAlice, the new version of the Alice virtual reality tool (built at CMU). They have terrible problems with pausing and catching in the middle of rendering (they had to totally give up on the laughable Java3D, and write JNI around DX8, which kinda misses the whole point, doesn't it?). It would render smoothly for a bit, and then just freeze for a significant fraction of a second, a couple times a second. They're still fighting the problems.
For the record. If you want to write it in Java, write it in C or C++. Don't give me the cross-platform BS, there are plenty of cross platform large C/C++ projects (all the Quakes; GNOME; Mozilla; the kernel). Carmack himself said (paraphrase) "I like the discipline being cross-platform brings to code". Arguing for Java on the basis of ease-of-coding (basically saying "I like GC") is a cop-out -- you're trading away a lot of speed because you're too lazy to manage your memory (I agree, it's tough. Everyone who writes code should be forced to pass CMU's OS class, 15-412, or restricted to writing HTML/JS/VB and nothing more complicated...). But even if Java was compiled just like C, it would be a lot slower, due to some fairly subtle language level tradoffs (basically the heavy reliance of Java on dynamic type and function resolution, and the fact that almost every primitive operation in the language requires doing such resolution).
But if you can write it in a language specialized to the task, do so. PERL can be gobbledygook hard to read. It can be quite elegant if coded well. But either way, I guarantee you the PERL will allow a much more concise representation of the problem. Compared to Java accessing SQL... even if the SQL parts run as fast, the Java will lag heavily in the REGEXPs, and will be no where near as clean as PERL at representing them in code.
I agree, it was unfair of me to rag on GlassCode under/.'ed loads. But it would be very interesting to do a performance comparison under ideal conditions.
(somewhat OT) Technical Comment about GlassCode
on
Glasscode Released
·
· Score: 1
(which is Half-Empty's Java servlet-base engine).
Those pages load hilariously slowly. I mean, the Slash engine is a hackish PERL monster, but it still loads at least front pages much faster, and did so even when/. was running on really old hardware (or does no one remember back that far?).
Of course I've never seen a JSP-based page that isn't dog slow.
Who else is amused by the fact the Java still can't deliver on its promises?
(This is a moderately subtle point; rewriting GlassCode in C/C++ wouldn't necessarily help, if its algorithms are dumb. They should have used the language appropriate to the problem, namely PERL. Hell, Java is terrible enough I bet C woulda been fine.)
- Standard Solaris functions for manipulating process contexts. Solaris is a great environment for all this, since everything is provided for you
- Special memory tricks. Rather than deal with the real SPARC pagetable structure, their support library uses a memory mapped file (mapped based on a simple 1-level page table provided by the kernel we write). This makes writing the paging code much easier.
- Signal handlers for things like SIGSEGV and all, as well as a timer that goes off. These are translated by the support library into kernel traps (which we write). So when a user program gets a SEGV for a memory access somewhere in the memmapped file, we change the page table some, the support library remaps things approrpriately, and we continue running. The timer is much slower than a real OS's timer, so a process's timeslice is slow enough a human can watch it go by (maybe 1/2 second or so).
So yeah. For all you people who thought you were doing everything, there really was a support library behind the curtain pulling the wool over your eyes. Norm and I cought the little man in there a couple of times doing funky things a couple of times (ever notice how you never have to worry about page table addresses when you switch from realmode to virtual memory? in theory you should have to be very careful to keep your page table from, say, falling across a physical page boundry when you allocate it with VM enabled. the support library ignores such details:).
Basically this ends up giving us a real kernel that's very very close to the Sun hardware. I actually asked Greg (professor this semester) why they didn't use Nachos. The answer had to do with the oversimplifications Nachos makes. Yalnix is a much more complete environment.
Actually, Greg says he's planning on redoing project 3 for next semester. He wants to take DR-DOS (or possible his own little minimalist DOS-like OS. This project would be on Intel intead of Sun hardware) and replace interrupt handlers one by one until you have UNIX. Since the DOS disk stuff would still be in place, he could then add demand paging to the project. He said this was the Clemson graduate OS project. For CMU undergrads, he'd write the asm utility functions, and also we'd have the advantage of VMWare or Plex86 (so when we crash ourselves all is not lost; this is a major advantage of Yalnix -- when you crash the OS, you get a core dump). The cool thing would be, when you were done, you could boot your OS for real on the hardware.
A note to people who aren't familiar with the CMU OS course: it's considered the hardest undergrad CS course (18 units, that's 6 credits). The last two projects are a month long each, easily 30-50 hours a week in the cluster. But when you're done and can say to recruiters, "Yeah I've taken OS and I got an A" they offer to hire you on the spot.
Ok, enough wasted time. I need to go back to my filesystem (project 4, due Friday at midnight. eep!)
If you did this, you wouldn't save your.o's if you crashed in the middle. So you'd lose all your work. So an hour into that m18 compile... and you'd have to do it all over (yuck!)
What you want is not to write your.o's unless you can safely write all of them (remember, you hit ^C in the middle of a compile, your object files are in good shape, so you can continue later).
Actually, Debian is more of a philosophy and a set of useful tools and concepts than anything else.
You could apply the Debian way to *any* reasonably centralizable operating system (so not 'doze, since it would be too hard to centrally distribute all the apps).
There is also work on a Debian-Solaris going on.
I don't think Debian as a whole has made any commitment to one over the other(s). As long as there are people willing to work on any given new Debian environment, they can do so without bothering the developers of the traditional 'Debian Classic' Linux distro.
You've clearly got a point there: in theory I shouldn't be able to decide to lower the security of data.
So you eliminate any way of creating a lower security file than the highest level of security you currently are. You can read anything you're cleared to, but can't possibly create a lower security file. The system could then have two paths
a) I can't log in at a lower security level so I can't under any circumstances share that information; you've removed all discretion from the process. Note that I could still walk down the hall and tell the uncleared janitor, verbally, anything I had learned.
b) I can log back in at a lower security level In which case I'll just memorize what I read before and write it into a new file at lower security.
You could argue that it's more secure since I can't do that algorithmically; I would have to literally memorize every character I wanted to commit. Certainly a gigabyte of nuclear research data would be hard to compromise that way.
But that doesn't sound like a Secure (in the OpenBSD or BugTRAQ "strongest-possible" sense) solution at all. Just because a secret file happens to be short and in English doesn't mean it should be easier to compromise, since "short and in English" is not part of the security description of the file. I would much rather have a traditional POSIX with well-planned access groups and discretionary security, and assume that anyone I show a file to can share it at lower security. In other words, since the leak is there, I would argue you should make it a flood (so it's unmistakable) rather than claiming it doesn't exist (since it obviously always does).
I note this is equally true of the "military-style" hardcopy document security system in the analogy in the post below. Which is probably why that's a dumb system.
Again, just my opinion. But I don't think MAC does anything more than obfuscate a truly insecure (in the sense that every human is insecure) system.
now that I've read all the little side-definitions...
the specs say you must rigorously separate the security-related portions of the system from those that are not security-related and Documentation must include a model of the security policy
Which really makes it sound like it's a very formal thing. But actually, [the security model] need not be a mathematical one, but it must be a clear statement of the rules
So... you have to have fine-grained control of everything that can affect system security. You have to define in a carefully documented hierarchy how the various security levels interact, and exactly what rights each one has. Doesn't sound too bad.
The Mandatory Access Controls (MAC) really sounds like a carefully documented ACL-set; it restricts access to system objects (eg. files, directories, devices) based on the sensitivity of the information in the object (represented by the object's label) and the authorization of the subject. Additionally, the system enforces the policy; users do not have the discretion to share their files. Slightly more compulsive than typical ACL rules, but nothing unreasonable.
It seems like you'd actually want to start with OpenBSD and use a very traditional POSIX style to approach this. The real work is in the documentation.
That said, save from the "rigourous testing" there's no hard guarantee this system is any safer. I'm not particularly impressed by this spec over the state of any reasonably secure UNIX. The real issue is not compliance with the spec itself, but how good your (documented) security policy is (and of course how well you've actually implemented it!). This whole spec really sounds like (imnsho) a way for you to bring in overpaid worthless consultants to read your policy/procedures, do some meaningless tests, and issue you a silly certification.
Shades of ISO9000, anyone?
This "Orange Book" sounds like a good idea at the beginning. But every definition in that glossary is at the level I would use to talk to my mother about computers: leave out all the subtleties or technical considerations. I think a system like WinNT could pass those specs with flying colours (if indeed it hasn't already) and still (duh) suck.
wtf "Orange Book B1" was. I went and found the following defin ition:
labeled security protection The B1 system class. B1 (and higher) systems support mandatory access controls. The system architecture must more rigorously separate the security-related portions of the system from those that are not security-related. Documentation must include a model of the security policy supported by the system. It need not be a mathematical one, but it must be a clear statement of the rules enforced by the system's security features. Testing is more stringent.
GNOME has made a lot of advancements on the "traditional" interface front (I mean all of Xerox-derived WIMP land), both in the "easy (or efficient) to use" and "easy to learn" departments. I find case after case, subtle and not-so-subtle, where GNOME is markedly better with its main competition, Windows and Mac. My favorite example of this is Evolution -- can't wait to try it. Evolution may finally tear me away from textmode mail clients....mmmm, query-able databases:)
My question is, where do you see GNOME as fitting in to more groundbreaking user interface research? Not that anyone expects the GNOME team to start pondering lexicons for 3D interfaces (or are you contemplating such things!?!). But there's lots of crazy stuff that still goes on in traditional, 2D interface design. A lot of recent research has been in terms of PDA interface design. Do you see GNOME, with its obvious advantages of modularity and scalability, as having a role to play in that arena?
And what about fundamental changes to the way we use our desktops? I for one haven't really changed at all since the days when I used fvwm1. Sure, things have gotten much prettier, and more applet-filled:) but i'm doing fundamentally the same things, and none of the various ways of configuring things (GNOME + sawmill = many ways of configuring things) have so far seemed particularly radical or any more efficient.
How 'bout the rest of the folks? Anyone done anything truly funky with sawmill? A Turing-complete wm is a fun place to start....
Slashdot Mirror
[describing his own various research interests
Role of p53 in Cancer
Our p53 studies are focused on the mechanism and role of this TSG in how normal tissues respond to genotoxic stresses associated with cancer treatment. Our previous studies have shown tissue specificity of p53-mediated apoptosis and its major role in determining the radiation sensitivity of mammals. We defined p53 as a determinant of cancer treatment side effects; the new therapeutic conceptâ"targeting p53 for therapeutic suppressionâ"was justified by isolating a small molecule p53 inhibitor that rescues mice from lethal doses of gamma irradiation.
Analysis of an animal model of chemotherapy-induced hair loss (alopecia) has indicated that p53 plays a major role in this common side effect, thus opening another area for clinical application of p53 inhibitors.
Mechanisms of tissue specificity of the p53 response are being addressed by cDNA microarray-based analysis of tissue-specific p53 responsive genes. This direction of studies is linked to identification of new tumor markers among the genes that are under the negative control of p53, a mechanism we have shown to be a possible underlying cause of elevated prostate-specific antigen expression.
The role of p53-dependent apoptosis and growth arrest and the interaction of p53 with other signaling pathways (TNF, Fas, heat shock, etc.) in determining its tumor suppressor function is being analyzed in several model systems. The impact of distinct p53 function (i.e., control of growth arrest or apoptosis) in its tumor suppressor activity is under investigation. We showed that control of radiosensitivity of tissues by p53 in vivo does not involve the p21/waf1 p53-responsive CDK inhibitor. Induction of apoptosis was found to be dispensable for p53-mediated control of genomic stability; moreover, suppression of p53-dependent apoptosis by Bcl-2 delays tumor progression by eliminating selective advantages for genetically unstable p53-deficient cells.
Having already defined ING1, Bloom syndrome and SUMO proteins as p53 interactors, we are continuing the search for cellular modulators of p53 expression and function among p53-interacting proteins; several additional candidates are under study.
Drug Discovery Program
Our drug discovery program involves searching for new p53 inhibitors and testing their potential therapeutic applications for reducing cancer treatment side effects and possibly other pathologies involving p53-inducing stresses. It is based on creation of new cell-based readout systems and high-throughput screening of chemicals with the desired biological properties.
We are also isolating a new class of small molecules acting as modulators of multi-drug transporters that can greatly change the pattern of cross-resistance, including the ability to enhance their activity against certain compounds. The molecular mechanisms of activity of newly isolated compounds are being addressed, as are therapeutic fields for their practical applications.
Collaborators:
>The discussion topic was about the nature of ethics. What are they, where >do they come from, etc. One of the things that came out in class was that >the majority of people in the class thought that ethical behavior came >from God. If you were an Athiest, you could not be ethical.
>Yes. Seriously.
For all the fact the libtool tag line is "Do you really want to worry about linking on AIX yourself?"...
... abnormal ... but you'd think libtool would know how to do it).
I spent quite a bit of time this summer trying to use autoconf'd stuff on AIX (Gtk+). I played with a pile of recent and not-so-recent versions of libtool. It was a pain in the butt. (Granted, linking on AIX is
I think the power of the autoconf suite to make things work across "all Unices" is a bit exaggerated. Check whether it really does a good job of supporting all the platforms you need, first.
Yes, actually :-)
/bin/sh, which is pure Bourne. HP-UX and AIX come with ksh).
Bash is (arguably) a piece of junk. And it's definitely not intended as a system scripting shell.
/bin/sh should be ksh or ash.
zsh is almost definitely a nicer end-user shell (but is, like bash, too bloated for system use).
...
(for the record, I think Solaris comes with "just" a
Just to play devil's advocate here for a minute -- if we're only ever allowed to implement what the standard dictates, how will we ever come up with anything new?
... that it's an evolution, and is different.
I mean, sure, you can sit down and write a totally new scripting language.
And no one will use it.
All computer systems change evolutionarily. C has evolved within itself quite a bit. C++ is a superset of C, with some caveats. Java is a language whose syntax inherits a lot from the C family, but is quite different.
Linux is like many other previous Unixes, except
It causes problems. It makes life difficult (everyone who's programmed Unix-like OSs knows that's a pain in the butt).
But are you seriously going to argue that we should have stuck to the one official narrow definition enshrined by ATT in the early 80s, and that no new implementation should differ in the least?
...
I would argue that "Embrace and extend" refers to, specifically, "Embrace and extend with non-standard, non-free additions that lock customers into our products and only our products, forever".
Anyone is free to make ksh or ash (or whatever) have a bash bug-compatibility mode to make people's lives easier in porting scripts. Hell, the Linux kernel has bug-compatible syscalls.
It's a pain. But it's also progress.
I apologize if my tone comes off confrontatively :-).
/bin/sh but use bash-specific features, I agree.
I'm reacting negatively to the idiotic suggestion that people need to waste time "writing a real Bourne shell for Linux".
If you don't like bash, there are several other shells which attempt to be POSIX. Some of them are quite strict (ash). Some are optimized for scripting (ksh).
If you want to argue that bash sucks and should be replaced as the default system scripting shell, I totally agree. If you want to say that it sucks when scripts request
But for goodness sake, give some respect to the work that's been done.
...
I did see one good post noting the bash specifics that are missing, as a POSIX shell. They really are quite minor...
Yes. I did.
/bin/sh. But I'd hazard to guess that 99% of the time those scripts are distro-specific in many other ways, so it doesn't really matter.
/bin/sh to ksh or ash, since all the system scripts will do slightly-non-POSIX things and therefore should be specifying /bin/bash).
And it was nonsensical.
If he's going to complain about bash being not exactly POSIX, he's got to show an example of an incompatibility (as a decent sometime bash and ksh hacker, I can't think of one -- and I can think of one subtlety that ksh and zsh do differently than POSIX: word splitting).
Ok. "export FOO=bar" doesn't work on a strictly-POSIX shell. But why is it bad for that to work in bash (and ksh and zsh)? How does that hurt you?
Instead, why doesn't the article's poster come up with an example of a valid POSIX statement that breaks in bash -- that way he actually has a complaint: he did something POSIX (i.e., the standard), and bash did the wrong thing. As it stands, he's just griping.
I mean, I agree with him -- bash is bloated and not a good choice for scripting. But that just means that scripts should be written in a shell optimized for scripting -- ksh. Or at least a minimalist straightforward POSIX shell (ash).
But if a system wants to provide just one POSIX shell (to save space, or whatever), and if bash is going to be used by 95% of users anyhow (so is likely to be loaded anyhow), making the one POSIX shell available on the system be bash isn't a bad call. Now that doesn't excuse scripts using non-POSIX features under the name of
I still have yet to see how (from anything but an efficiency perspective), this guy is finding that bash somehow makes his life harder.
(side-point: it is annoying that you can't solve the efficiency problem by relinking
...
I apologize for my confrontational tone. It really irks me when people propose writing things without bothering to check if the work has been done for them. I mean, come on, guys, it's Free Software. Avoiding duplication is the name of the game.
I won't be the first to say this, but oh well.
/bin/sh and then commit travesties like "export FOO=bar".
"WHAT CAVE DID YOU JUST CRAWL OUT OF?!"
Ok. ksh and zsh are supersets of the POSIX shell. And I agree, strictly speaking it's bad to shebang
But give me a break.
If you want to script, you have no excuse to be using anything other than ksh (or just maybe ash).
AIX comes with only ksh in the way of POSIX-shells.
Why do we have to live like there has been zero progress since the original POSIX shell spec? And who could be so brain-damaged as not to notice ksh, the unquestioned pinnacle of scripting shells, and zsh, the unquestioned epitome of user shells?
Gee whiz. Don't waste your time; go write something useful.
(....grumble, grumble, idiotic duplication of effort....)
The point about critical-section efficiency on MP systems is pretty key. I think that calls for a multithreaded, multiprocessing retest ...
But in any case, if your application is spending a significant amount of time grinding on waits for mutex constructs (i.e. any of the syscalls discussed), you're having a bad day -- it means your threads are spending a lot of time in critical sections, and are going to spend a lot of time waiting for each other.
There are schools of concurrent design where you typically have threads blocked on a mutex waiting to move forward, but I don't think those are particularly high-performance models in the first place. Better to stick to the old dictum: "minimize the critical section", both in length and in frequency.
(caveat: I think microkernels are silly firewalls in code that should be correct and trusted)
There are going to be speed problems with any microkernel-based OS -- OS X is not necessarily exempt either.
Basically, if you spend a lot of time copying data between address spaces of different chunks of the kernel, you're going to pay for it. If you have to switch address spaces to switch kernel tasks, you're going to pay for it (in cache misses).
Even in a monolithic-kernel OS (which will always be superior, if you assume the parts of the kernel are well-enough written that they can be trusted by other parts of the kernel), you have some cost moving data from userspace to kernel space. You can get around that in clever cases -- Linux does this with zerocopy networking, passing sets of (physical) pages around and dumping them directly to the card driver.
As Linus once said "Mantra: `Everything is a stream of bytes'. Repeat until enlightened." In other words, any obsessiveness that gets in the way of moving streams of bytes around extremely efficiently is not good architecture. Message passing (and separate address spaces for kernel "server" modules) fall into this category.
1) "Competition has no other choice than to buy product from Baby Bell."
2) "Undercut the competition until it's gone, then raise prices."
Number 1 sounds like a monopoly to me.
Number 2 sounds like a monopoly violating anti-trust law.
Contact your Better Business Bureau. Find some smart lawyers who want to make a buck. Does anyone else think it's time for a class-action suit?
[Verizon just raised DSL prices in the Pittsburgh area too. I'm just lucky that CMU decided to raise their prices as well and keep running their private happy little DSL service for students & profs]
I also noticed (over the past few years) that Sun has been leaning on the UltraII since like 1999.
:)
Back then they were way ahead of the game, since Intel/AMD were doing about a quarter their current clock speed, while Sun was doing about half.
I wonder what happened
Hmm, Not really.
I mean, yeah, they're totally different. And they're faster clock-per-clock (with added benefit to FP stuff).
But a 1.4GHz Athlon blows away a 7-800MHz UltraII for most kinds of computation. A 1 GHz Athlon seems to be about (42, 29) on the (retired) SPECint95/SPECfp95. A 450Mhz Ultra-II (not Ultra-IIi, I'm looking at results for an SPARCstation Ultra-60) gets about (20, 27). That's a bit faster int clock-per-clock, and a lot faster FP. Note that for practical stuff (databases, web, whatever) int is more important. Of course benchmarks are hard to interpret, but this gives you an idea. All the SPEC benchmarks are available at www.specbench.org. Of course there are no Ultra-III results, but I'm guessing it's not going to be 2x as fast as the best x86s (at least I'll wait to see the results before I believe it).
You use a Sun because you want an architecture that will scale smoothly up to 64-way (I *guarantee* that will be faster than any single x86 machine).
Actually if you want to both go fast at the low end and scale well, you can buy an RS/6000 -- IBMs Power3 and Power4 chips are absurdly fast and scale very well (and actually focus on memory bandwidth for database performance). But a bottom-of-the-line Sun is a lot cheaper than the cheapest RS/6000.
Full disclosure: I work for IBM (in software) and I've seen a good bit of internal stuff about IBM chips, esp. the upcoming Power4. Most of that information has now been published in MicroProcessor Review and is now publicly available, I think you'll find it if you poke around...
(even more amusing full disclosure: I'm a huge fan of old Sun stuff, their machines are beautifully engineered. i use a couple old 32bit sparcs for all kinds of things)
Actually, Java is at a huge loss with its native libraries.
Languages like PERL and Python know they're natively slow, so they do all the real work underneath in C/C++ libs (that's how PERL's regexp's fly, and how Python-Numeric is within a small constant factor of number crunching in straight C).
But Java has some *terrible* langauge design choices that really limit speed:
- Everything is an Object. This means that you can't have typed containers (i.e. templates), so you have to do expensive dynamic-downcasts when you remove objects from the container (heh, in C you'd just say "I know it's a struct foo*!" and cast away happily".
- Except *not* everything is an object -- primitive types are second-class citizens, so to use the container library on ints or floats you have to use the heavy capital-I-Integer, etc
- All method calls are virtual. This is a small but insidious memory-lookup on every function call... (can be avoided in most places in C++, but is sometimes necessary).
...
If you really want to go fast, you use OCaML -- C and C++ are relatively speaking very hard languages to optimize. Strong typing (without Java's silly "strongly typed, then throw away the type info!") allows you to do much more rigourous analysis at compile time, so you have a much stronger picture of what the data flow graph is. For example, in C/C++ it's almost impossible to draw the data flow graph anywhere but in the basic block (think "within a set of {}") -- and even to do that the optimizer is making assumptions. In OCaML the data flow diagram contains the whole program, so the compiler can optimize across function calls.
...
Note to the lisp junkies: get over syntax. Someone should write a "straight abstract syntax tree" frontend to OCaML just to make you guys happy. Gee whiz.
Not to be an apologist for a software program I woiuldn't use in a million years, but ...
.... less credible than the whole story about Odysseus (giant cyclops included).
...):
.....
Word 2000 runs *beautifully* on my mother's ancient Toshiba P120 laptop, with 48mb of ram. It was pretty slow with the evil continuous spelling/syntax checking on, but with that off, it starts almost as quickly as good old WordPerfect 6 (previous word processor, came out in about '93), and runs about as fast.
...
Of course the myths about Windows having a sane setup for program installation and system installation are
I have *never* seen a better method for program installation than Ximian's RedCarpet, btw.
...
That said, speaking as a Linux programmer (several different Free projects: SashXB, VPython
"I don't give a damn whether anyone else finds Linux useful".
I use and hack Linux because it's what *I* want. I don't care if it beats any other operating system. If other people happen to find my stuff useful, fine. But I'm not going to adulterate it at the cost of user choice. When I do intro-to-Unix (primarily Solaris) classes for the CS freshmen at CMU, the point I stress is that TMTOWTDI
This is the meat of the matter. Dead on, you saved me an identical post :).
This is the impracticability that Bruce Schneier is talking about: if factoring is secure enough that it would take Eve a year (or 1000 years) to break an RSA-encoded message --- if you need to go from public-key to extremely strong stream/block cypher, you can use RSA to exchange a secret, then use Blum-Goldwasser squaring, which is as strong as factoring (if computationally expensive) --- then the assaulter is going to look for another weak link. For 99.99% of all crypto applications (and maybe it really is 100%), being secret for a good period of time (which you can adjust with key length) is as good as perfectly secret, forever.
OTP is certainly not new. And in fact it's only ever been governments who have the resources to put it into practice. Generating random numbers even at just enough rate to cover all your text is not cheap. No you can't use a cryptorandom number generator. Think about it, if it was an algorithmic generator, you could just give both parties copies of your unbreakable but deterministic generator -- they'd exchange the secret start value by RSA, or when Alice and Bob meet in a dark alley -- and you wouldn't need any satellites, or to generate pad at 10^6^6 numbers a second. I guess to generate pad that quickly, you'd need to do some quantum observation with a 50/50 split or something -- you certainly can't have monkeys up on your satellite rolling dice that quick (believe it or not, during WWII, RAND Corp. used to produce the OTP sheets, generated by people rolling dice).
So yeah. I'm not impressed with this guy.
Bwahahahaahha!
/., being marked a troll is beyond funny :)
:)
... even if the SQL parts run as fast, the Java will lag heavily in the REGEXPs, and will be no where near as clean as PERL at representing them in code.
/.'ed loads. But it would be very interesting to do a performance comparison under ideal conditions.
Most of my posts make it to 5 (check my karma if you don't believe me). Especially considering how rarely I post to
Honestly, i don't see why an observation about the performance of GlassCode isn't a valid comment when the code itself is released.
Yes, I'm an anti-Java person. I think i'm a pretty well justified one, in general. I honestly have yet to see the Java system that performs as advertised. Now maybe GlassCode really is just under the weather and is usually better, but you'll forgive me. My last two anecdotal Java experiences were:
- Using the SameTime (IBM's message client, used a lot internally there) Java client on Linux. The beast took 90 megs of space (RSS). By contrast, the SashXB SameTime client (which my group wrote), took only 30 megs, and ran much more responsively (this was on GHz pIII's, running IBM's absolute-latest JITC-based JRE). And the SashXB version was written in JavaScript on top of Mozilla
- Using JAlice, the new version of the Alice virtual reality tool (built at CMU). They have terrible problems with pausing and catching in the middle of rendering (they had to totally give up on the laughable Java3D, and write JNI around DX8, which kinda misses the whole point, doesn't it?). It would render smoothly for a bit, and then just freeze for a significant fraction of a second, a couple times a second. They're still fighting the problems.
For the record. If you want to write it in Java, write it in C or C++. Don't give me the cross-platform BS, there are plenty of cross platform large C/C++ projects (all the Quakes; GNOME; Mozilla; the kernel). Carmack himself said (paraphrase) "I like the discipline being cross-platform brings to code". Arguing for Java on the basis of ease-of-coding (basically saying "I like GC") is a cop-out -- you're trading away a lot of speed because you're too lazy to manage your memory (I agree, it's tough. Everyone who writes code should be forced to pass CMU's OS class, 15-412, or restricted to writing HTML/JS/VB and nothing more complicated...). But even if Java was compiled just like C, it would be a lot slower, due to some fairly subtle language level tradoffs (basically the heavy reliance of Java on dynamic type and function resolution, and the fact that almost every primitive operation in the language requires doing such resolution).
But if you can write it in a language specialized to the task, do so. PERL can be gobbledygook hard to read. It can be quite elegant if coded well. But either way, I guarantee you the PERL will allow a much more concise representation of the problem. Compared to Java accessing SQL
I agree, it was unfair of me to rag on GlassCode under
(which is Half-Empty's Java servlet-base engine).
/. was running on really old hardware (or does no one remember back that far?).
Those pages load hilariously slowly. I mean, the Slash engine is a hackish PERL monster, but it still loads at least front pages much faster, and did so even when
Of course I've never seen a JSP-based page that isn't dog slow.
Who else is amused by the fact the Java still can't deliver on its promises?
(This is a moderately subtle point; rewriting GlassCode in C/C++ wouldn't necessarily help, if its algorithms are dumb. They should have used the language appropriate to the problem, namely PERL. Hell, Java is terrible enough I bet C woulda been fine.)
I can flesh that out a little bit.
:).
The codebase is only really
- Standard Solaris functions for manipulating process contexts. Solaris is a great environment for all this, since everything is provided for you
- Special memory tricks. Rather than deal with the real SPARC pagetable structure, their support library uses a memory mapped file (mapped based on a simple 1-level page table provided by the kernel we write). This makes writing the paging code much easier.
- Signal handlers for things like SIGSEGV and all, as well as a timer that goes off. These are translated by the support library into kernel traps (which we write). So when a user program gets a SEGV for a memory access somewhere in the memmapped file, we change the page table some, the support library remaps things approrpriately, and we continue running. The timer is much slower than a real OS's timer, so a process's timeslice is slow enough a human can watch it go by (maybe 1/2 second or so).
So yeah. For all you people who thought you were doing everything, there really was a support library behind the curtain pulling the wool over your eyes. Norm and I cought the little man in there a couple of times doing funky things a couple of times (ever notice how you never have to worry about page table addresses when you switch from realmode to virtual memory? in theory you should have to be very careful to keep your page table from, say, falling across a physical page boundry when you allocate it with VM enabled. the support library ignores such details
Basically this ends up giving us a real kernel that's very very close to the Sun hardware. I actually asked Greg (professor this semester) why they didn't use Nachos. The answer had to do with the oversimplifications Nachos makes. Yalnix is a much more complete environment.
Actually, Greg says he's planning on redoing project 3 for next semester. He wants to take DR-DOS (or possible his own little minimalist DOS-like OS. This project would be on Intel intead of Sun hardware) and replace interrupt handlers one by one until you have UNIX. Since the DOS disk stuff would still be in place, he could then add demand paging to the project. He said this was the Clemson graduate OS project. For CMU undergrads, he'd write the asm utility functions, and also we'd have the advantage of VMWare or Plex86 (so when we crash ourselves all is not lost; this is a major advantage of Yalnix -- when you crash the OS, you get a core dump). The cool thing would be, when you were done, you could boot your OS for real on the hardware.
A note to people who aren't familiar with the CMU OS course: it's considered the hardest undergrad CS course (18 units, that's 6 credits). The last two projects are a month long each, easily 30-50 hours a week in the cluster. But when you're done and can say to recruiters, "Yeah I've taken OS and I got an A" they offer to hire you on the spot.
Ok, enough wasted time. I need to go back to my filesystem (project 4, due Friday at midnight. eep!)
This is actualy completely not what you want.
.o's if you crashed in the middle. So you'd lose all your work. So an hour into that m18 compile ... and you'd have to do it all over (yuck!)
.o's unless you can safely write all of them (remember, you hit ^C in the middle of a compile, your object files are in good shape, so you can continue later).
If you did this, you wouldn't save your
What you want is not to write your
Actually, Debian is more of a philosophy and a set of useful tools and concepts than anything else.
You could apply the Debian way to *any* reasonably centralizable operating system (so not 'doze, since it would be too hard to centrally distribute all the apps).
There is also work on a Debian-Solaris going on.
I don't think Debian as a whole has made any commitment to one over the other(s). As long as there are people willing to work on any given new Debian environment, they can do so without bothering the developers of the traditional 'Debian Classic' Linux distro.
You've clearly got a point there: in theory I shouldn't be able to decide to lower the security of data.
So you eliminate any way of creating a lower security file than the highest level of security you currently are. You can read anything you're cleared to, but can't possibly create a lower security file. The system could then have two paths
a) I can't log in at a lower security level
so I can't under any circumstances share that information; you've removed all discretion from the process. Note that I could still walk down the hall and tell the uncleared janitor, verbally, anything I had learned.
b) I can log back in at a lower security level
In which case I'll just memorize what I read before and write it into a new file at lower security.
You could argue that it's more secure since I can't do that algorithmically; I would have to literally memorize every character I wanted to commit. Certainly a gigabyte of nuclear research data would be hard to compromise that way.
But that doesn't sound like a Secure (in the OpenBSD or BugTRAQ "strongest-possible" sense) solution at all. Just because a secret file happens to be short and in English doesn't mean it should be easier to compromise, since "short and in English" is not part of the security description of the file. I would much rather have a traditional POSIX with well-planned access groups and discretionary security, and assume that anyone I show a file to can share it at lower security. In other words, since the leak is there, I would argue you should make it a flood (so it's unmistakable) rather than claiming it doesn't exist (since it obviously always does).
I note this is equally true of the "military-style" hardcopy document security system in the analogy in the post below. Which is probably why that's a dumb system.
Again, just my opinion. But I don't think MAC does anything more than obfuscate a truly insecure (in the sense that every human is insecure) system.
now that I've read all the little side-definitions ...
... you have to have fine-grained control of everything that can affect system security. You have to define in a carefully documented hierarchy how the various security levels interact, and exactly what rights each one has. Doesn't sound too bad.
the specs say you must rigorously separate the security-related portions of the system from those that are not security-related and Documentation must include a model of the security policy
Which really makes it sound like it's a very formal thing. But actually, [the security model] need not be a mathematical one, but it must be a clear statement of the rules
So
The Mandatory Access Controls (MAC) really sounds like a carefully documented ACL-set; it restricts access to system objects (eg. files, directories, devices) based on the sensitivity of the information in the object (represented by the object's label) and the authorization of the subject. Additionally, the system enforces the policy; users do not have the discretion to share their files. Slightly more compulsive than typical ACL rules, but nothing unreasonable.
It seems like you'd actually want to start with OpenBSD and use a very traditional POSIX style to approach this. The real work is in the documentation.
That said, save from the "rigourous testing" there's no hard guarantee this system is any safer. I'm not particularly impressed by this spec over the state of any reasonably secure UNIX. The real issue is not compliance with the spec itself, but how good your (documented) security policy is (and of course how well you've actually implemented it!). This whole spec really sounds like (imnsho) a way for you to bring in overpaid worthless consultants to read your policy/procedures, do some meaningless tests, and issue you a silly certification.
Shades of ISO9000, anyone?
This "Orange Book" sounds like a good idea at the beginning. But every definition in that glossary is at the level I would use to talk to my mother about computers: leave out all the subtleties or technical considerations. I think a system like WinNT could pass those specs with flying colours (if indeed it hasn't already) and still (duh) suck.
My $0.02.
wtf "Orange Book B1" was. I went and found the following defin ition:
labeled security protection
The B1 system class. B1 (and higher) systems support mandatory access controls. The system architecture must more rigorously separate the security-related portions of the system from those that are not security-related. Documentation must include a model of the security policy supported by the system. It need not be a mathematical one, but it must be a clear statement of the rules enforced by the system's security features. Testing is more stringent.
GNOME has made a lot of advancements on the "traditional" interface front (I mean all of Xerox-derived WIMP land), both in the "easy (or efficient) to use" and "easy to learn" departments. I find case after case, subtle and not-so-subtle, where GNOME is markedly better with its main competition, Windows and Mac. My favorite example of this is Evolution -- can't wait to try it. Evolution may finally tear me away from textmode mail clients....mmmm, query-able databases :)
:) but i'm doing fundamentally the same things, and none of the various ways of configuring things (GNOME + sawmill = many ways of configuring things) have so far seemed particularly radical or any more efficient.
....
My question is, where do you see GNOME as fitting in to more groundbreaking user interface research? Not that anyone expects the GNOME team to start pondering lexicons for 3D interfaces (or are you contemplating such things!?!). But there's lots of crazy stuff that still goes on in traditional, 2D interface design. A lot of recent research has been in terms of PDA interface design. Do you see GNOME, with its obvious advantages of modularity and scalability, as having a role to play in that arena?
And what about fundamental changes to the way we use our desktops? I for one haven't really changed at all since the days when I used fvwm1. Sure, things have gotten much prettier, and more applet-filled
How 'bout the rest of the folks? Anyone done anything truly funky with sawmill? A Turing-complete wm is a fun place to start