Right, so the 2nd article states "I should note that this particular exploit requires that the attacker already have admin or root privileges on the box" -- and "The exploit code was only written for Intelâ(TM)s DQ35 motherboards. The DQ35 is one of their modern boards. According to Joannaâ(TM)s paper, Intel reported that their newest motherboards (DQ45â(TM)s for example) are not vulnerable to this attack.". In short, it's an interesting proof of concept, but at first glance it's not exactly the scare of the century....
I'd be surprised if _only_ 1% of H1-B visa are from europe, considering the inexistence of other options if you are from the EU and you want to work in the US (there are a couple of others visa for specialized jobs as well, iirc). All the europeans I know that know work in the US are either under a H1-B or started with one before applying for a green card.
Care to give some links about this ? All I read about the H1B "grace" period is that there is none. (random recent link http://www.isss.umn.edu/H1BEmployment/GracePer.html). There's apparently an unofficial 10 day grace period, but that's about it.
The ST movie was supposed to be an insult to Heinlein, parodying the fascist leanings of his work, not an "accurate" adaptation
Indeed -- when I saw that movie I kinda liked it, for the in your face irony and criticism of medias, action movies, propaganda -- remember the blatant propaganda shown on tv, the SS uniforms, etc. It was absolutely _obvious_ this was a parody and critical of all it was showing.
I was astounded to read reviews on the web (on/. itself iirc) that actually took the movie as if it was a straight action flick...
I can only concur. I've got an iliad since a couple of months, and it's fantastic:)
It has some issues, but overall is worth it (and it's not like the other available devices are better).
I wrote some impressions here: http://camaelon.blogspot.com/2008/04/iliad-irex-note-taking-and-hand-writing.html
My only reserve is that you have to get the shell access to really take advantage of it -- but I don't think it's a problem that's really annoying for slashdot readers ! It's a really cool hacking platform.
Not really. Javadoc/Doxygen are taking a program and generating a "documentation" (more a reference really). CWEB and similar tools take a documentation and generate a program. It's not just a question of doing it in the other direction -- the results won't be the same (ie, a LP documentation will be much better). But Javadoc/Doxygen have a much, much lower entry barrier, and they do provide something useful, so, better than nothing...
In LaTex it's even worse. No support for stylesheets and defining or even getting colors is a pain in the ass. Just look at that:
the WHOLE point of LaTeX is to provide stylesheets. Sure you can go back to mix content and presentation, you can even write TeX code if you so wish. But LaTeX is all about separating your content from its representation! Beside it's entirely YOUR problem if you choose to write {\large \textcolor{ref}{I'm annoying!}} rather than the more succing and more accurante \moron{I'm annoying!}...
And now you can mod me flamebait or even troll, I don't care. That's why I'm posting anonymously after all;)
It probably have more to do with the fact you're giving stupid reasons to dislike LaTeX.
Literate Programming is not about making programming languages incredibly verbose; it's about *describing* your program in a normal, human way, by explaining it step by step and quoting bits and pieces of the program. Sounds ideal from a documentation point of view, right ? only that if that was all there was with Literate Programming, it would be a stupid idea, as documentation has a nasty habit to not follow up with code modification.
The really cool idea with LP is that the code snippets you use in the documentation are then weaved together to generate the "real" code of your program. So a LP document is BOTH the documentation and the code. A code snippet can contains references ("include") to other code snippets, and you can adds stuff to an existing code snippet.
Let me show you an example in simple (invented) syntax:
{my program}
{title}My super program{/title}
Blablabla we'd need to have the code organized in the following loop:
{main}:
{for all inputs}:
{filter inputs}
{apply processing on the filtered inputs}
{/} {/}
The {for all inputs} consist in the following actions:
{for all inputs}:
some code {/}
The filtering first remove all blue inputs:
{filter inputs}:
remove all blue inputs {/}... and then remove all the green inputs:
{filter inputs}+:
remove all green inputs {/}
etc.
{/}
The above is purely to illustrate the idea, the actual CWEB syntax is a bit different. But you can see how, starting with a single source document, you could generate both the code and the documentation of the code, and how you can introduce and explain your code gradually, explaining things in whichever way that makes the most sense (bottom-up, top-down, a mix of those..).
In a way, Doxygen or JavaDoc have similar goals: put documentation and code together and generate documentation. But they take the problem in reverse from what literate programming propose; with Doxygen/JavaDoc, you create your program, put some little snippets of documentation, and you automatically generate a documentation of your code. With LP, you write your documentation describing your program and you generate the program.
Those two approaches produce radically different results -- the "documentation" created by Doxygen/JavaDoc is more a "reference" kind of documentation, and does little to explain the reason of the program, the choice leading to the different functions or classes, or even something as important as explaining the relationships between classes. With some effort it's possible to have such doc system be the basis of nice documentation (Apple Cocoa documentation is great in that aspect for example), but 1/ this requires more work (Cocoa has descriptive documents in addition to the javadoc-like reference) 2/ it really only works well for stuff like libraries and frameworks.
LP is great because the documentation is really meant for humans, not for computers. It's also great because by nature it will produces better documentation and better code. It's not so great as it poorly integrates with the way we do code nowadays, and it poorly integrates with OOP.
But somehow I've always been thinking that there is a fundamentally good idea to explore there, just waiting for better tools/ide to exploit it:-P
(also, the eponymous book from Knuth is a great read)
It's very well known. When I was a freshman in CS (in 96!), most of the teaching was done in Ada (some of the profs were really big on it), and they described the problem. As far as I remember, this is what happened: - they chose to reuse a previous components made for Ariane 4 (ok...) - they chose to NOT test it as it was working fine on Ariane 4 after all... in order to "cut costs" - the flight parameters were quite different between Ariane 4 and 5, and notably, some were out of the range experienced with Ariane 4 - an exception was thus triggered in the component (which had something to do with navigation system), but there was no code to handle it (iirc there was code, but it had been disabled when compiling the component) - the default exception mechanism was executed, and decided to reset the full navigation system - the rocket then changed behaviour (duh!) and started to veer off from the planned flight path, and at that point a ground engineer decided to blow it up.
To sum it up: by deciding to "cut" cost by not testing a component they lost millions of euros. Nothing the language could have done, really.
I never had to program in Ada after my BS, but I did like the language. It really felt like an engineering language you could rely on -- we joked at the time that if you could compile your code, your program was probably right. On the other hand it was quite verbose and the compilator was really strict (but with wonderful error messages, never found something as good since).
Funnily I'm myself very keen on dynamic languages (ObjC/Smalltalk...) and usually don't like static languages. Still, kinda like Ada.
Smalltalk has been around for ages. If it's so great then how come it never caught on?
If you look at Smalltalk today, this question is indeed absolutely inexplicable, and when you start programming in Smalltalk you just can't understand how is it possible at all that it's not used everywhere (at the very least, it should be much, much more present than it is). It's the closest thing to an ideal programming world (ok, I probably should include lisp on a lisp machine).
That beeing said, it's sadly fairly explicable:
Smalltalk environments were BLOODY EXPENSIVE (and needed expensive workstations to run usually). We now have some very high quality free VM that works on any OS. And even the expensive commercial Smalltalk are now affordable or even free for non-commercial use.
Smalltalk was slow ! (of course now it's not a concern, for various reasons; mainly we now have very, very fast machines, and also Smalltalk VM are much much faster, some with JIT, etc. See Strongtalk...)
Smalltalk "looks weird" to an imperative programmer (and believe me, I wouldn't call C++ an object-oriented language, so I readily include C++ programmers in that list)
Not file-based, but image-based. Quite unsettling at first, and can leads to some annoyance (but also brings so much power that it's an easy tradeoff to make!)
So basically, 1/ It was not familiar, with a quite big conceptual jump to make (procedural to true OOP) 2/ It was not easily accessible 3/ It was slow. Of those 3 reasons, the first two are very likely the reason why Smalltalk didn't take over the world. That doesn't mean it shouldn't.
There's another reason sometimes quoted about Smalltalk: That it's so great that companies just do not advertise its use: it's a competitive weapon.
The irony of course for reason #3 (slowness) is the last fad language is Ruby (which I do quite like), who happens to be magnitude slower than the slowest Smalltalk.
But again, writing your OWN templating engine is absolutely trivial, if you really need to do so. Yet somehow it doesn't stick with Seaside because even the ones that did write and release such templating engines ends up realizing they are more a burden than a good thing.
And frankly, if your designers don't know how to design with CSS... you have a problem.
But anyway, this whole point is moot. Even if the designer handles me some weird template page, it will be fairly trivial to take the template and stick it into Seaside -- remember, in Seaside you are not working with HTML, you work with Smalltalk code that happens to map to html.
Therefore, you usually do not use the 1:1 mapping between said code and html to create your pages/components, but rather group bits and pieces of the "html" you need as full Smalltalk methods. Yay for html refactoring ! (and that's without even talking about the components model).
Between this possibility and the components, you end up working at a high description level; you express the structure and logic of the "page", not how it looks or even which bits of html it will output. Therefore it really is no more trouble to add some pure HTML if you need to because your designer hasn't learn a damn thing in ten years than to add whatever additional divs you'd need to your high level structure in order to accommodate the cool CSS design your competent designer would have come with. I'm probably not clear enough, but believe me, templates are not the problem with Seaside. Play a bit with it, you'll see.
Seaside would change the world, if only it had better support for templating.
That's pretty much wrong. For once, it's trivial to implement templating in Seaside. And guess what ? there was at least two or three templates implementation for Seaside. What happened to them ? I'm not even sure they are still maintained (I'd doubt it in fact). Why ? simply because templating brought little value to Seaside.
Templating was crucial ten years ago. WebObjects was fantastic for that for example. But now, with CSS ? screw templating ! it's much, much better to have programmers outputing html via seaside and designers putting nice CSS clothes on top it.
Why better ? because if you do it like Seaside does it, eg not by directly mixing HTML code with actual program code, but by having an "HTML" api in your language that output the html... well, you have all the joy of using Seaside (Smalltalk) development environment, the refactoring tools, etc, that apply to both your code and your html. There is thus no difference between refactoring your code and refactoring the html code -- they are both smalltalk code.
"Sometimes" ? technically, yes, apparently (though that comes as a complete surprise to me).
But to be fair, according to aufeminin.com, the highest ever (per year) is 68 individuals while it is 23320 for the male version. 1:343 is not "sometimes" in my book, it's frigging random occurence:)
We didn't copy the image, jesse recreated something that was close.. yes it does look similar, perhaps too much (though there's so many thing you can do if you want a plain looking icon for a speaker!) but we certainly didn't just copy the image. The rounded corners are indeed an obvious nod to apple -- there's no denying that Etoile is somehow inspired by OSX graphically, and many of us use OSX regularly.
Their efforts are not to create a MacOS X skin, but rather an OS compatible with cocoa. From the developers perspective, if they can achieve near parity with the cocoa libraries (they already had a great start since they had OpenStep), then you can just recompile a MacOS X application to run on this GNUStep based OS. In my opinion, this represents a quantum leap in the opensource movement. Stop trying to copy the knuckleheads in Redmond, and start copying the guys in Cupertino.
Actually... we aren't particularly aiming at an OS compatible with Cocoa. We are compatible, indeed, but it's a (nice) side effect of beeing based on GNUstep, it's a bonus, but not our primary goal. We are not particularly aimed at copying OSX either; it's just that OSX happend to be really good (mostly) and we want to use some of its ideas. Similarly we are influenced by NeXTSTEP, by Smalltalk, NewtonOS, etc.
That beeing said, as we are using the GNUstep libraries, it is relatively easy to port a Cocoa application to Etoile, simply because it's also pretty straightforward to port a Cococa application to GNUstep in the first place... So we have a certain source compatibility with Cocoa, to the extent that GNUstep has it. But our main goal is not to produce an OSX clone.
We want to create a good, component/document oriented desktop environment. It's a lot of work and we are just at the beginning. It's also rather likely that we'll always be a "small" desktop, as what we want is not exactly what current popular desktop environment are aiming for, and maybe we are also completely mistaken in thinking that our approach will be much better. Note also that the current 0.2 release is still rather close to a normal desktop, but we are planning quite different things for the future (much closer to NewtonOS or a Smalltalk system than to Windows...) : widespread use of CoreObject, Assistant tech, etc.
So in the end it just amount to the fact that we are kinda bored with the current desktop approach and we prefer to work on our free time on something that isn't afraid to try really different approach than working on cloning Windows (gasp!) or even MacOS X. Current Linux Desktop provides a good enough solution for that.
(ps: as an aside I totally agree though that Etoile could help GNUstep gains some traction and nothing would please me more)
GNUStep is reasonably compatible with NextStep which is reasonably compatible with Cocoa. They branched from a common ancestor and happen to be reasonably similar now. All the extra frameworks tossed in to this project looks to be a third fork more than a bridge between the two.
Uh... we aren't forking GNUstep at all. Many of the Etoile developers are also GNUstep developers...:)
What we do provide and will continue to provide are additional frameworks. Those are obviously free software as well, and anybody is welcome to compile them on OSX; as a matter of fact, many of them already works on OSX, as quite a few devs program on OSX. But anyway... it's just a side effect of beeing based on GNUstep/OpenStep, we don't especially want to be compatible with OSX -- I repeat myself, but we aren't doing an OSX clone and that was never our goal.
The idea that people should get a free pass because they're not paid to do it is likewise absurd. These developers are not children. They don't get a writeoff for failing to capture the essence and for missing the point. If they want to invite comparisons to other products and want to put something in the public eye, then they can accept the consequences that result, which includes criticism.
In general, I would agree with you. But if you had taken two minutes reading OUR website and not the misleading/. summary, you'd have realized that we DO NOT MAKE ANY CLAIM to be a MacOS-like environment (As in fact, we actually don't want MacOS X, we want something else.). Now, we do gladly accept criticism, and you are more than welcome to discuss UI issues on our mailing list : we actually are very UI focused, and I assure you that we think it's important. But as others said, this is only a 0.2 release, and many things will improve, we know that very well...
The "yardstick," further, is clear: they (be they/. editors or developers) threw down the gauntlet and said "Mac-like" while coughing up a poor approximation. Success and failure are determined by their ability to capture the theme. It's abundantly clear that this is sorely lacking. If you disagree, then be a rational adult and do it. I've outlined a few of the many ways they fail to measure up. Demonstrate how they ARE Mac-like if you can. The summary put itself in with the big kids and it can't hold its weight. You can't seem to divorce yourself from your rabid feelings and don't seem to know anything about space and weight, to say nothing of design in general, so I won't hold my breath for an intelligent response.
Well, you can't really hold on to us that the/. post is misleading ? Your whole premise is that we claimed that, and then you proceed to detail where we fail in that goal. And I totally agree ! Contrary to what you think, we are not claiming to be an OSX clone, we don't want to be one, and we are FAR from saying that we provide here a perfect thing: there are lots of things to do, to fix, to clean up, be it in the code or on the UI. And people are welcolme to provide constructive critiscism and give us a hand;-) but at the same time you should also understand that it's "just" a 0.2 release and we are perfectly aware that we have a lot to do...
Sigh.. what happened to the whole premise "Release Early, Release Often":-P [and we're far to that too...]
The Amiga was wayyyy ahead of its time -- it had separate graphics, sound and I/O processors and made use of DSPs years before the equivalent began showing up in 'IBM-compatibles' and Macs.
Er... the ST had separate graphics, sound and I/O processors as well. Ok, the graphic (less colors) and sound ( less channels if I remember) ones weren't as good as the amiga:) but on the other hand, the ST had high-res and midi i/o, which is why it was a great machine for DTP (Calamus) and music (Cubase), and why it was used as such. Strangely the ST was marketized as a game machine in the uk, but afaik more used as a pro/dtp machine in germany, and in france a bit in between (eg, bastardized. Lots of missed opportunities).
I'm curious about your claim about using a DSP in an amiga 500 though.
Now if you are not talking about later amiga... may I remind you the Atari TT030 (I still have one), a really great machine (68030, vga, possibility to plug in a 1280x960 monochrome display... told you, DTP..), and the Falcon030, which technically was indeed a really cool thing (DSP56001, etc).
For those unaware, GNUstep got accepted this year... So if you want to discover a neat little OO language (Objective-C), and work on a really great framework, don't hesitate !
GNUstep is a free implementation of the OpenStep API, cross-platform (windows, linux, etc), close to Apple's Cocoa (ie, Cocoa is itself an extension of the OpenStep API, so in fact you can port Cocoa app to GNUstep and vice-versa -- GNUstep can now even read/write apple nibs natively). In addition to the frameworks, there's nice development tools, in particular Gorm, the GNUstep's pendant to InterfaceBuilder.
Check the GNUstep wiki to see a list of potential projects !
Slashdot Mirror
Right, so the 2nd article states "I should note that this particular exploit requires that the attacker already have admin or root privileges on the box" -- and "The exploit code was only written for Intelâ(TM)s DQ35 motherboards. The DQ35 is one of their modern boards. According to Joannaâ(TM)s paper, Intel reported that their newest motherboards (DQ45â(TM)s for example) are not vulnerable to this attack.". In short, it's an interesting proof of concept, but at first glance it's not exactly the scare of the century....
I'd be surprised if _only_ 1% of H1-B visa are from europe, considering the inexistence of other options if you are from the EU and you want to work in the US (there are a couple of others visa for specialized jobs as well, iirc). All the europeans I know that know work in the US are either under a H1-B or started with one before applying for a green card.
Care to give some links about this ? All I read about the H1B "grace" period is that there is none. (random recent link http://www.isss.umn.edu/H1BEmployment/GracePer.html). There's apparently an unofficial 10 day grace period, but that's about it.
The ST movie was supposed to be an insult to Heinlein, parodying the fascist leanings of his work, not an "accurate" adaptation
/. itself iirc) that actually took the movie as if it was a straight action flick...
Indeed -- when I saw that movie I kinda liked it, for the in your face irony and criticism of medias, action movies, propaganda -- remember the blatant propaganda shown on tv, the SS uniforms, etc. It was absolutely _obvious_ this was a parody and critical of all it was showing. I was astounded to read reviews on the web (on
I posted a blog entry with some pictures: http://camaelon.blogspot.com/2008/05/iliad-irex-pictures.html and a previous post about the iliad and other stuff: http://camaelon.blogspot.com/2008/04/iliad-irex-note-taking-and-hand-writing.html The Mobile Read forums are also pretty informative. On the capacity to annotate pdf, I think that's one of the great use case of the iliad -- you can easily read & annotate on the iliad, then transfert back the PDF+annotations, and merge them in a new PDF -- or even only create a PDF with annotated pages.
I can only concur. I've got an iliad since a couple of months, and it's fantastic :)
It has some issues, but overall is worth it (and it's not like the other available devices are better).
I wrote some impressions here: http://camaelon.blogspot.com/2008/04/iliad-irex-note-taking-and-hand-writing.html
My only reserve is that you have to get the shell access to really take advantage of it -- but I don't think it's a problem that's really annoying for slashdot readers ! It's a really cool hacking platform.
Not really. Javadoc/Doxygen are taking a program and generating a "documentation" (more a reference really). CWEB and similar tools take a documentation and generate a program. It's not just a question of doing it in the other direction -- the results won't be the same (ie, a LP documentation will be much better). But Javadoc/Doxygen have a much, much lower entry barrier, and they do provide something useful, so, better than nothing...
In LaTex it's even worse. No support for stylesheets and defining or even getting colors is a pain in the ass. Just look at that:
the WHOLE point of LaTeX is to provide stylesheets. Sure you can go back to mix content and presentation, you can even write TeX code if you so wish. But LaTeX is all about separating your content from its representation! Beside it's entirely YOUR problem if you choose to write {\large \textcolor{ref}{I'm annoying!}} rather than the more succing and more accurante \moron{I'm annoying!} ...
And now you can mod me flamebait or even troll, I don't care. That's why I'm posting anonymously after all ;)
It probably have more to do with the fact you're giving stupid reasons to dislike LaTeX.
Literate Programming is not about making programming languages incredibly verbose; it's about *describing* your program in a normal, human way, by explaining it step by step and quoting bits and pieces of the program. Sounds ideal from a documentation point of view, right ? only that if that was all there was with Literate Programming, it would be a stupid idea, as documentation has a nasty habit to not follow up with code modification.
... and then remove all the green inputs:
:-P
The really cool idea with LP is that the code snippets you use in the documentation are then weaved together to generate the "real" code of your program. So a LP document is BOTH the documentation and the code. A code snippet can contains references ("include") to other code snippets, and you can adds stuff to an existing code snippet.
Let me show you an example in simple (invented) syntax:
{my program}
{title}My super program{/title}
Blablabla we'd need to have the code organized in the following loop:
{main}:
{for all inputs}:
{filter inputs}
{apply processing on the filtered inputs}
{/}
{/}
The {for all inputs} consist in the following actions:
{for all inputs}:
some code
{/}
The filtering first remove all blue inputs:
{filter inputs}:
remove all blue inputs
{/}
{filter inputs}+:
remove all green inputs
{/}
etc.
{/}
The above is purely to illustrate the idea, the actual CWEB syntax is a bit different. But you can see how, starting with a single source document, you could generate both the code and the documentation of the code, and how you can introduce and explain your code gradually, explaining things in whichever way that makes the most sense (bottom-up, top-down, a mix of those..).
In a way, Doxygen or JavaDoc have similar goals: put documentation and code together and generate documentation. But they take the problem in reverse from what literate programming propose; with Doxygen/JavaDoc, you create your program, put some little snippets of documentation, and you automatically generate a documentation of your code. With LP, you write your documentation describing your program and you generate the program.
Those two approaches produce radically different results -- the "documentation" created by Doxygen/JavaDoc is more a "reference" kind of documentation, and does little to explain the reason of the program, the choice leading to the different functions or classes, or even something as important as explaining the relationships between classes. With some effort it's possible to have such doc system be the basis of nice documentation (Apple Cocoa documentation is great in that aspect for example), but 1/ this requires more work (Cocoa has descriptive documents in addition to the javadoc-like reference) 2/ it really only works well for stuff like libraries and frameworks.
LP is great because the documentation is really meant for humans, not for computers. It's also great because by nature it will produces better documentation and better code. It's not so great as it poorly integrates with the way we do code nowadays, and it poorly integrates with OOP.
But somehow I've always been thinking that there is a fundamentally good idea to explore there, just waiting for better tools/ide to exploit it
(also, the eponymous book from Knuth is a great read)
It's very well known. When I was a freshman in CS (in 96!), most of the teaching was done in Ada (some of the profs were really big on it), and they described the problem. As far as I remember, this is what happened:
- they chose to reuse a previous components made for Ariane 4 (ok...)
- they chose to NOT test it as it was working fine on Ariane 4 after all... in order to "cut costs"
- the flight parameters were quite different between Ariane 4 and 5, and notably, some were out of the range experienced with Ariane 4
- an exception was thus triggered in the component (which had something to do with navigation system), but there was no code to handle it (iirc there was code, but it had been disabled when compiling the component)
- the default exception mechanism was executed, and decided to reset the full navigation system
- the rocket then changed behaviour (duh!) and started to veer off from the planned flight path, and at that point a ground engineer decided to blow it up.
To sum it up: by deciding to "cut" cost by not testing a component they lost millions of euros. Nothing the language could have done, really.
I never had to program in Ada after my BS, but I did like the language. It really felt like an engineering language you could rely on -- we joked at the time that if you could compile your code, your program was probably right. On the other hand it was quite verbose and the compilator was really strict (but with wonderful error messages, never found something as good since).
Funnily I'm myself very keen on dynamic languages (ObjC/Smalltalk...) and usually don't like static languages. Still, kinda like Ada.
If you look at Smalltalk today, this question is indeed absolutely inexplicable, and when you start programming in Smalltalk you just can't understand how is it possible at all that it's not used everywhere (at the very least, it should be much, much more present than it is). It's the closest thing to an ideal programming world (ok, I probably should include lisp on a lisp machine).
That beeing said, it's sadly fairly explicable:
So basically, 1/ It was not familiar, with a quite big conceptual jump to make (procedural to true OOP) 2/ It was not easily accessible 3/ It was slow. Of those 3 reasons, the first two are very likely the reason why Smalltalk didn't take over the world. That doesn't mean it shouldn't.
There's another reason sometimes quoted about Smalltalk: That it's so great that companies just do not advertise its use: it's a competitive weapon.
The irony of course for reason #3 (slowness) is the last fad language is Ruby (which I do quite like), who happens to be magnitude slower than the slowest Smalltalk.
But again, writing your OWN templating engine is absolutely trivial, if you really need to do so. Yet somehow it doesn't stick with Seaside because even the ones that did write and release such templating engines ends up realizing they are more a burden than a good thing.
And frankly, if your designers don't know how to design with CSS... you have a problem.
But anyway, this whole point is moot. Even if the designer handles me some weird template page, it will be fairly trivial to take the template and stick it into Seaside -- remember, in Seaside you are not working with HTML, you work with Smalltalk code that happens to map to html.
Therefore, you usually do not use the 1:1 mapping between said code and html to create your pages/components, but rather group bits and pieces of the "html" you need as full Smalltalk methods. Yay for html refactoring ! (and that's without even talking about the components model).
Between this possibility and the components, you end up working at a high description level; you express the structure and logic of the "page", not how it looks or even which bits of html it will output. Therefore it really is no more trouble to add some pure HTML if you need to because your designer hasn't learn a damn thing in ten years than to add whatever additional divs you'd need to your high level structure in order to accommodate the cool CSS design your competent designer would have come with. I'm probably not clear enough, but believe me, templates are not the problem with Seaside. Play a bit with it, you'll see.
Seaside would change the world, if only it had better support for templating.
That's pretty much wrong. For once, it's trivial to implement templating in Seaside. And guess what ? there was at least two or three templates implementation for Seaside. What happened to them ? I'm not even sure they are still maintained (I'd doubt it in fact). Why ? simply because templating brought little value to Seaside.
Templating was crucial ten years ago. WebObjects was fantastic for that for example. But now, with CSS ? screw templating ! it's much, much better to have programmers outputing html via seaside and designers putting nice CSS clothes on top it.
Why better ? because if you do it like Seaside does it, eg not by directly mixing HTML code with actual program code, but by having an "HTML" api in your language that output the html... well, you have all the joy of using Seaside (Smalltalk) development environment, the refactoring tools, etc, that apply to both your code and your html. There is thus no difference between refactoring your code and refactoring the html code -- they are both smalltalk code.
"Sometimes" ? technically, yes, apparently (though that comes as a complete surprise to me).
:)
But to be fair, according to aufeminin.com, the highest ever (per year) is 68 individuals while it is 23320 for the male version. 1:343 is not "sometimes" in my book, it's frigging random occurence
We didn't copy the image, jesse recreated something that was close.. yes it does look similar, perhaps too much (though there's so many thing you can do if you want a plain looking icon for a speaker!) but we certainly didn't just copy the image. The rounded corners are indeed an obvious nod to apple -- there's no denying that Etoile is somehow inspired by OSX graphically, and many of us use OSX regularly.
Actually... we aren't particularly aiming at an OS compatible with Cocoa. We are compatible, indeed, but it's a (nice) side effect of beeing based on GNUstep, it's a bonus, but not our primary goal. We are not particularly aimed at copying OSX either; it's just that OSX happend to be really good (mostly) and we want to use some of its ideas. Similarly we are influenced by NeXTSTEP, by Smalltalk, NewtonOS, etc.
That beeing said, as we are using the GNUstep libraries, it is relatively easy to port a Cocoa application to Etoile, simply because it's also pretty straightforward to port a Cococa application to GNUstep in the first place... So we have a certain source compatibility with Cocoa, to the extent that GNUstep has it. But our main goal is not to produce an OSX clone.
We want to create a good, component/document oriented desktop environment. It's a lot of work and we are just at the beginning. It's also rather likely that we'll always be a "small" desktop, as what we want is not exactly what current popular desktop environment are aiming for, and maybe we are also completely mistaken in thinking that our approach will be much better. Note also that the current 0.2 release is still rather close to a normal desktop, but we are planning quite different things for the future (much closer to NewtonOS or a Smalltalk system than to Windows...) : widespread use of CoreObject, Assistant tech, etc.
So in the end it just amount to the fact that we are kinda bored with the current desktop approach and we prefer to work on our free time on something that isn't afraid to try really different approach than working on cloning Windows (gasp!) or even MacOS X. Current Linux Desktop provides a good enough solution for that.
(ps: as an aside I totally agree though that Etoile could help GNUstep gains some traction and nothing would please me more)
Uh... we aren't forking GNUstep at all. Many of the Etoile developers are also GNUstep developers... :)
What we do provide and will continue to provide are additional frameworks. Those are obviously free software as well, and anybody is welcome to compile them on OSX; as a matter of fact, many of them already works on OSX, as quite a few devs program on OSX. But anyway... it's just a side effect of beeing based on GNUstep/OpenStep, we don't especially want to be compatible with OSX -- I repeat myself, but we aren't doing an OSX clone and that was never our goal.
Err... can you point me to that ? Because I'm pretty sure we don't :)
In general, I would agree with you. But if you had taken two minutes reading OUR website and not the misleading /. summary, you'd have realized that we DO NOT MAKE ANY CLAIM to be a MacOS-like environment (As in fact, we actually don't want MacOS X, we want something else.). Now, we do gladly accept criticism, and you are more than welcome to discuss UI issues on our mailing list : we actually are very UI focused, and I assure you that we think it's important. But as others said, this is only a 0.2 release, and many things will improve, we know that very well...
The "yardstick," further, is clear: they (be they /. editors or developers) threw down the gauntlet and said "Mac-like" while coughing up a poor approximation. Success and failure are determined by their ability to capture the theme. It's abundantly clear that this is sorely lacking. If you disagree, then be a rational adult and do it. I've outlined a few of the many ways they fail to measure up. Demonstrate how they ARE Mac-like if you can. The summary put itself in with the big kids and it can't hold its weight. You can't seem to divorce yourself from your rabid feelings and don't seem to know anything about space and weight, to say nothing of design in general, so I won't hold my breath for an intelligent response.
Well, you can't really hold on to us that the /. post is misleading ? Your whole premise is that we claimed that, and then you proceed to detail where we fail in that goal. And I totally agree ! Contrary to what you think, we are not claiming to be an OSX clone, we don't want to be one, and we are FAR from saying that we provide here a perfect thing: there are lots of things to do, to fix, to clean up, be it in the code or on the UI. And people are welcolme to provide constructive critiscism and give us a hand ;-) but at the same time you should also understand that it's "just" a 0.2 release and we are perfectly aware that we have a lot to do...
:-P [and we're far to that too...]
Sigh.. what happened to the whole premise "Release Early, Release Often"
Er... the ST had separate graphics, sound and I/O processors as well. Ok, the graphic (less colors) and sound ( less channels if I remember) ones weren't as good as the amiga :) but on the other hand, the ST had high-res and midi i/o, which is why it was a great machine for DTP (Calamus) and music (Cubase), and why it was used as such. Strangely the ST was marketized as a game machine in the uk, but afaik more used as a pro/dtp machine in germany, and in france a bit in between (eg, bastardized. Lots of missed opportunities).
I'm curious about your claim about using a DSP in an amiga 500 though.
Now if you are not talking about later amiga... may I remind you the Atari TT030 (I still have one), a really great machine (68030, vga, possibility to plug in a 1280x960 monochrome display... told you, DTP..), and the Falcon030, which technically was indeed a really cool thing (DSP56001, etc).
For those unaware, GNUstep got accepted this year ... So if you want to discover a neat little OO language (Objective-C), and work on a really great framework, don't hesitate !
GNUstep is a free implementation of the OpenStep API, cross-platform (windows, linux, etc), close to Apple's Cocoa (ie, Cocoa is itself an extension of the OpenStep API, so in fact you can port Cocoa app to GNUstep and vice-versa -- GNUstep can now even read/write apple nibs natively). In addition to the frameworks, there's nice development tools, in particular Gorm, the GNUstep's pendant to InterfaceBuilder.
Check the GNUstep wiki to see a list of potential projects !