Except at the "IE only" site point in history, you could still get IE for Macs, for free. No licence needed.
IE for Mac was a total disaster. not only it was as non-standard as IE4-5, but it was not even similar to IE for windows. In fact, you had a higher probability of an IE-only page working on Netscape than on IE for Mac.
Don't use an older box, get a newer box with a CPU that does virtualization. That makes all the difference.
1: no CPU 'does virtualization', unless you're talking about bit IBM's POWER machines, or such 2: VMWare Server doesn't use current processors' VMX / SVM extensions, so they don't make _any_ difference. 3: Xen and KVM do use them, in fact can't run windows (or at all in KVM's case) without them. so the difference isn't about performance, is about being able to do it.
the trick is to put the color filter needed for color LCD _behind_ the LCD itself, and turn the backlit off.
I remember using my Palm III on bright sunlight by turning the backlit off. it was really good. now, a modern LCD, with thinner walls, and higher contrast would be even better. and having color capabilities when you want them, is just great
interesting... but six months is too short. even now, most 'supposed to be serious' HDDs are available with at least 1 year warranty.
a few years ago that was usually 3 years, with 5 years available. going to 1 year is obviously a bad sign about quality and resiliency; but still more than 6 months!
if your anecdote is significant, all it means is that 'technologically educated users' are more probable to use Apple machines.
what the parent post says is that most Apple users are 'technologically uneducated'. i see no contradiction, given how uneducated outnumber educated users.
even more, it's still possible that the fraction of 'educated' users is even lower in apple users than pc machines. personally, i don't believe that; but since using windows demands hearing lots of geekspeak, most windows users might sound like they're more 'technologically educated' than mac users, which doesn't have to worry about all these.
Plasmoids can be programmed in a whole slew of languages, such as Ruby, JS, Python, C++, etc. Someone made a proof-of-concept Firefox extension that ran plasmoids in your browser.
AFAIK, those plasmoids were only the ones that where any programming was JS. or maybe it could run other kinds outside the browser process but displaying in the same window. not useful as a start for multi-language web programming.
Chrome comes with Gears, and can't Gears widgets be programmed in a variety of languages?
no, it's still JS only.
the only parts in C are inside the plugin itself, not useful if you want to depend on a single version of the plugin
And Java is still around, etc.
even if several 'good' languages are getting compilers that target JVM, these usually don't mean the applet environment. for example Jython runs on tomcat servers, not on the browser.
worse, some of them (Clojure, Scala) are hopelessly handicapped because JVM design is tied to Java design. (for example Clojure doesn't have real tail-call optimisation, so any Scheme programmer would get lots of stack overflows for trivial functions. also cons pairs are implemented with objects, making them immensely heavier in space and time than a real LISP implementation)
Or, you can do what the Pyjamas etc. people do - be ok with writing the syntax of Python but having the semantics of JavaScript. It's a hybrid language, and you'll always run into corners and bugs that are hard to figure out if you do anything interesting, but stick to conventional code and you might do ok.
only if 'conventional' python code doesn't include something as popular as list comprehensions.
yes, i know that it's a young project, and features are added daily; but it amounts to a new compiler with all the disadvantages of JS and only a few of the nice things of Python (which wouldn't be my first choice either). better just write JS.
browser development would only get really comfortable if NativeClient gets stable and popular, so you can use the real C compilers of good languages (Lua! real Python, Scheme?) without worrying about weird corner cases introduced by a tall and wiggly tower of languages over languages.
the main problem of these compilers is that since JS have high-level constructs but with unoptimal semantics (not even talking about performance...), they have to reimplement their own containers.
take Pyjamas for example: Python has dicts, JS has objects, in the surface they're close enough, so you'd want to use them to implement the other; but there are _lots_ of corner cases that mean you have to either check lots of access patterns and emulate the desired behavior, or, more likely, just give up and reimplement the whole structure using arrays as if they were C memory buffers (that's what Alchemy does).
in the end, it would be far better to just use a real bytecode VM with JIT capabilities to run compiled 'small applications'.. lets call them 'applets'?
the language itself is mostly compatible across browsers. the main problem is premature standardisation, see crockford's website to see how the language design was frozen before it was tested enough. so now we're stuck with terrible design decisions, like the 'which' keyword, the changing meaning of 'this', the 'not-quite-lexical' scoping of 'var', etc.
(of course, that's besides the DOM incompatibilities, and even worse, CSS completeness)
i usually develop on Linux, and test against Konqueror and Firefox 3, and periodically fireup a KVM virtual machine running winXP for testing against IE, Chrome, and Firefox (again).
when doing heavy JS animations, and even more when using Canvas, it's pretty obvious that FF on windows is far smoother than on Linux, even with the VM overhead.
I'd say that there are lots of optimizations that the FF/Linux dev team left out.
totally right..NET is a rehash of win32, even if it's more sane and modern, its really un-POSIX, so Mono is always a second-tier. running a.NET app on Mono is always the second option.
and worse, writing basic desktop components in Mono is like saying win32 is better than POSIX. remember beagle? the popularity of that slow and bloated thing made desktop search on Linux lag years behind mac and windows.
it's so depressing to read Miguel's blog posts, he's always so excited to be redoing new things from MicroSoft, visiting there to find what's new... he might be a great programmer, but it's so obvious he's following and not leading.
Slashdot Mirror
Except at the "IE only" site point in history, you could still get IE for Macs, for free. No licence needed.
IE for Mac was a total disaster. not only it was as non-standard as IE4-5, but it was not even similar to IE for windows. In fact, you had a higher probability of an IE-only page working on Netscape than on IE for Mac.
been there, done that. never again.
Calvin: Verbing weirds language.
Hobbes:Maybe we can eventually make language a complete impediment to understanding.
Don't use an older box, get a newer box with a CPU that does virtualization. That makes all the difference.
1: no CPU 'does virtualization', unless you're talking about bit IBM's POWER machines, or such
2: VMWare Server doesn't use current processors' VMX / SVM extensions, so they don't make _any_ difference.
3: Xen and KVM do use them, in fact can't run windows (or at all in KVM's case) without them. so the difference isn't about performance, is about being able to do it.
similar experience here. i used up to 10.4 on my iMac DV (400Mhz G3 with 384MB RAM). 10.5 is too slow, OTOH
when Improv appeared, excel was already a best-selling on the mac.
this is not e-ink. it's reflective LCD.
the trick is to put the color filter needed for color LCD _behind_ the LCD itself, and turn the backlit off.
I remember using my Palm III on bright sunlight by turning the backlit off. it was really good. now, a modern LCD, with thinner walls, and higher contrast would be even better. and having color capabilities when you want them, is just great
interesting... but six months is too short. even now, most 'supposed to be serious' HDDs are available with at least 1 year warranty.
a few years ago that was usually 3 years, with 5 years available. going to 1 year is obviously a bad sign about quality and resiliency; but still more than 6 months!
there was a qbasic in most CP/M system disks. yes, it came from Microsoft
If anything is misleading, it's the "100% reliable" part.
that's a quote from the time the flaw was discovered. the news today is that Apple is the only one still vulnerable.
Scribus is 'page layout' software.
So are InDesign and (arguably) TeX.
It would be the perfect thing to arrange pre-rendered LaTeX, exported as Postscript or some other neutral format, within a larger document.
AFAIK, it doesn't have any real equation or graphics generation capabilities of its own. Someone please prove me wrong! :)
The next version has promised LaTeX frames, where you directly import live LaTex content, not pre-rendered
most of /proc is either disabled, virtualised or useless in VMs, since they can't really affect the real hardware
any software running on a VM is limited to that VM, no matter how rooted is the VM's OS, it doesn't have access to the real CPU's MTRR
if your anecdote is significant, all it means is that 'technologically educated users' are more probable to use Apple machines.
what the parent post says is that most Apple users are 'technologically uneducated'. i see no contradiction, given how uneducated outnumber educated users.
even more, it's still possible that the fraction of 'educated' users is even lower in apple users than pc machines. personally, i don't believe that; but since using windows demands hearing lots of geekspeak, most windows users might sound like they're more 'technologically educated' than mac users, which doesn't have to worry about all these.
Every last prominent newspaper in the western world supported that war.
that's a very narrow definition of 'western world', one that only includes USA and UK.
i really can't believe how wrong you are
Only they show up late with products that are usually tied to their OS platform and maybe a little dorky.
Doesn't that describe IE?
Plasmoids can be programmed in a whole slew of languages, such as Ruby, JS, Python, C++, etc. Someone made a proof-of-concept Firefox extension that ran plasmoids in your browser.
AFAIK, those plasmoids were only the ones that where any programming was JS. or maybe it could run other kinds outside the browser process but displaying in the same window. not useful as a start for multi-language web programming.
Chrome comes with Gears, and can't Gears widgets be programmed in a variety of languages?
no, it's still JS only.
the only parts in C are inside the plugin itself, not useful if you want to depend on a single version of the plugin
And Java is still around, etc.
even if several 'good' languages are getting compilers that target JVM, these usually don't mean the applet environment. for example Jython runs on tomcat servers, not on the browser.
worse, some of them (Clojure, Scala) are hopelessly handicapped because JVM design is tied to Java design. (for example Clojure doesn't have real tail-call optimisation, so any Scheme programmer would get lots of stack overflows for trivial functions. also cons pairs are implemented with objects, making them immensely heavier in space and time than a real LISP implementation)
Or, you can do what the Pyjamas etc. people do - be ok with writing the syntax of Python but having the semantics of JavaScript. It's a hybrid language, and you'll always run into corners and bugs that are hard to figure out if you do anything interesting, but stick to conventional code and you might do ok.
only if 'conventional' python code doesn't include something as popular as list comprehensions.
yes, i know that it's a young project, and features are added daily; but it amounts to a new compiler with all the disadvantages of JS and only a few of the nice things of Python (which wouldn't be my first choice either). better just write JS.
browser development would only get really comfortable if NativeClient gets stable and popular, so you can use the real C compilers of good languages (Lua! real Python, Scheme?) without worrying about weird corner cases introduced by a tall and wiggly tower of languages over languages.
Lua isn't built into the browser of almost every computer on the planet.
neither is Flash... but it's everywhere.
all we need is NativeClient to suceed just as widely
the main problem of these compilers is that since JS have high-level constructs but with unoptimal semantics (not even talking about performance...), they have to reimplement their own containers.
take Pyjamas for example: Python has dicts, JS has objects, in the surface they're close enough, so you'd want to use them to implement the other; but there are _lots_ of corner cases that mean you have to either check lots of access patterns and emulate the desired behavior, or, more likely, just give up and reimplement the whole structure using arrays as if they were C memory buffers (that's what Alchemy does).
in the end, it would be far better to just use a real bytecode VM with JIT capabilities to run compiled 'small applications'.. lets call them 'applets'?
the language itself is mostly compatible across browsers. the main problem is premature standardisation, see crockford's website to see how the language design was frozen before it was tested enough. so now we're stuck with terrible design decisions, like the 'which' keyword, the changing meaning of 'this', the 'not-quite-lexical' scoping of 'var', etc.
(of course, that's besides the DOM incompatibilities, and even worse, CSS completeness)
yes! please!!! almost any other modern language would be preferable over JS!
i keep dreaming of Lua on the browser...
of course, if NativeClient ever gets stable and popular enough, it would be dead easy to use whatever language you wish to compile
i usually develop on Linux, and test against Konqueror and Firefox 3, and periodically fireup a KVM virtual machine running winXP for testing against IE, Chrome, and Firefox (again).
when doing heavy JS animations, and even more when using Canvas, it's pretty obvious that FF on windows is far smoother than on Linux, even with the VM overhead.
I'd say that there are lots of optimizations that the FF/Linux dev team left out.
totally right. .NET is a rehash of win32, even if it's more sane and modern, its really un-POSIX, so Mono is always a second-tier. running a .NET app on Mono is always the second option.
and worse, writing basic desktop components in Mono is like saying win32 is better than POSIX. remember beagle? the popularity of that slow and bloated thing made desktop search on Linux lag years behind mac and windows.
it's so depressing to read Miguel's blog posts, he's always so excited to be redoing new things from MicroSoft, visiting there to find what's new... he might be a great programmer, but it's so obvious he's following and not leading.