I've put serious learning time in on at least 5 different general-purpose 3D graphics packages, including Blender. Blender is, hands-down, the hardest to learn and use of any I've tried. It even beat out a hoary old beast from the late 90's I had to use for a course, which was chosen purely because it was ancient and therefore cheap.
There are those that use the excuse, "It's professional grade, and pros don't cry about difficult to use tools." Well, sorry, but that only flies when there are no alternatives. If there's only one tool that does Thing X and the tool sucks, well, a pro will grit his teeth and use it anyway. That's not the case in 3D modeling / animation / rendering software. We have an embarrassment of choices, and they span a wide range of cost, power, and ease of use. Unless "freeeeee" is your only important criterion, there are usually better options than Blender, at least as of 2.4x.
I will certainly be playing with this new 2.5 version. Maybe they're right. Maybe they've completely fixed it all, and I can get off the Cinema4D, modo and SketchUp upgrade treadmills.
Commercial SSH has always just pretty much been for suckers...
That's probably true if you refer only to command line ssh.
For GUI SSH, however, spending a bit of coin can be very much worth it.
I have to use Windows on my work desktop, from which I help manage hundreds of remote Linux boxen. It would be madness to do that that with PuTTY, with its horrible UI, or with ssh in a Cygwin window, where session management is entirely missing, unless you count ~/.ssh/config. The commercial GUI SSH client we use[*] lets us organize all those sessions, save login info, and sync all that among the handful of computers used by the people who I help with those remote servers. A user name, password, or IP changes about once a week, somewhere. Managing that with just command line tools would be less efficient. Further, we get features like a tabbed UI, integrated file transfer, scripting, etc. We pay back our hundred bucks a seat in efficiency pretty quickly.
[*] no point naming it, I'm not here to sell anyone anything
"Very timidly"? Nonsense. You want an example of open source timidity, look at Microsoft: how many substantial open-source programs do they provide? By comparison, Sun was profligate. Oracle is a clear regression back along the continuum toward the Microsoft end.
The question in my mind is, does Oracle actually intend to regress like this, or are we just seeing the fallout of standard merger problems? Is this all just stemming from mismanagement, resource allocation battles, and general confusion, or is there a mandate from the top to regress?
If you're lost in the mountains, simply knowing which tower received the SMS message would probably help the SAR team a lot.
Besides, this would allow SAR to hold a slow IM-like conversation with the lost person. They could describe their surroundings, coordinate movements, give status updates, etc.
It would be nice if the FCC would also raise the cap on radio strength when sending messages to 911. It should be able to temporarily jump to, say, 5 W to burst the SMS out. Even if this is only one-way, it'd probably save a lot of lives.
He was a cult hero long before he began bashing on Powerpoint. That's just the thing he happens to be known for best now, probably because more people have to build Powerpoint presentations than have to design infographics.
If the 35S I bought a few months ago is any indication, they're back on the right path. They're not the same as the 1990's and earlier generation HPs I have, but they suck a lot less.
I hear the 50G is part of this return to high build quality standards, but I haven't tried one myself.
Sure, it'll suck down a lot of power, which is why I don't use mine as a server. I use it as a secondary desktop, so it can sleep most of the day away. It's absolutely fine for that.
Only use that G5 as a server if you can actually keep the thing busy most of the time.
You can keep your clocks accurate with something that isn't inherently unstable and complex, like RADclock. Or for leaf nodes, you can stay with the same basic protocol but jettison a lot of the complexity by switching to SNTP.
The problem with DocBook XML + MathML is that most DocBook processors (i.e. XML-FO formatters) don't support MathML. I'm only aware of one XML-FO processor that will do this, AntennaHouse's XSL Formatter with the MathML add-on. Versions of this start at $400, which isn't horrible considering what it does.
With only one choice, you have to take the whole bag of features as a whole, or lose out on MathML. I bought a formatter from one of AntennaHouse's competitors because I needed some of its features more than I needed MathML support. I ended up hacking a GNU make based system to format the equations in LaTeX form to both PDF and GIF formats, which I then included as illustrations in the DocBook document. (The PDF equations get included in the PDF version of the final document, and the GIFs get included in the HTML version.) It's a fairly ugly hack, but the resulting document looks nice, so I'll live with it.
What this discovery does is completes the set of possible passive devices; we've found them all now, there will be no more. Everything else you're talking about are active devices, which I would argue cannot be reduced to a fundamental set.
To contrast the two, let's think about how we would define the fundamental set of semiconducting active devices. The simplest is a diode: it's just a PN junction. Everything else is made of different arrangements of P and N material, plus insulators. A bipolar transistor is a PNP or NPN arrangement, and there are two ways to run one "backwards" and get a diode, one using a PN path, the other NP. But you can't just solder a pair of discrete diodes together and get a bipolar transistor; the physical arrangement of the materials matters. And if arrangement of materials matters, is a FET fundamental, or is it just part of the class of devices called "transistors"? Where do UJTs, SCRs, triacs, and IGBTs fit? I say these are all variations on a theme with infinite possibilities. It's like with music: you can't draw a line around certain sounds and say "those within are musical notes, and those without are not".
By contrast, the set of passives is a fixed-size set, with each element being completely unlike any other. An ideal inductor has no capacitance and no resistance; an ideal resistor has no capacitance or inductance; and an ideal capacitor has no resistance or inductance. (Real ones have parasitic elements of the others, but there's no fundamental mathematical requirement for this.) We can draw a line around this set and say, "this is fundamental, all passive circuits are built on these elements".
First, consider Flash itself. It started as an animation tool, but in the past few releases, it's gained a lot of application development power. It's now on par with every modern development environment from a pure capability standpoint: Java,.NET, Python, Perl, modern web browsers...you name it. The only thing more powerful is native code.
Even if you're a software developer, you probably didn't know that because the Flash authoring environment is a horrid way to write a typical program. Its source code editing facilities are nearly as poor as using Notepad, and the environment's architecture centers on the timeline and drawing tools. For a code-heavy project, it's the wrong tool for the job. Software developers ignore it, and rightly so.
Enter Flex Builder. This is an Eclipse-based IDE for working with ActionScript code and compiling it to Flash SWF files. Anything you can build in the Flash authoring environment, you can do in Flex Builder, but the weaknesses and strengths are inverted: it's great for code heavy projects, poor for ones heavy on the graphics and animation. It also includes the Flex application framework, which offers all the typical facilities you find in other application frameworks: GUI controls, network I/O mechanisms, file I/O, XML parsing, database interaction... Plus, everything available in the Flash ActionScript API is there, too.
All of this has existed for years now. What's new are AIR, and the open sourcing of the Flex framework and command-line tools.
Flex applications run in a web browser, using the Flash plugin for that browser. The AIR runtime includes enough of a web browser to support the Flash plugin and Flex applications, plus some new APIs for local filesystem access, printing, etc. Basically, it lets a Flex app break free from the web browser, and provides enough additional facilities to make it worthwhile to do so.
The Flex framework and command line tools let you build your own development environment to replace Flex Builder. You can now build Flex applications with any text editor, and build system you like. Rather use vi than Eclipse? Now you can. Want to hack on the tools themselves, rather than build applications? Go ahead. All Adobe is keeping for themselves now is the runtime; this seems sensible to me given the history of competing runtime environments. (Write once, debug everywhere.) Adobe also has the standard development environments, but they've given the world all the tools they need to compete directly.
If you want to get a sense of what Flex is capable of, see Adobe's own flagship demo applications. I recommend Kuler, Photoshop Express, and Buzzword. I don't believe any of these have compelling AIR versions yet, but to imagine the AIR version, just imagine that you can run any of these without a web browser, and without being connected to the Internet. It's that seamless a transition from a Flex app to an AIR app.
Just like C/C++ it's completely possible to write an AIR application to performs malicious actions.
Yes, some malicious possibilities exist, mostly stemming from the fact that AIR lets you access the local file system with the full permissions of the user running the app. As long as the file system is reasonably secured, though, the maximum damage should be limited to user files only. Because the runtime doesn't let AIR apps call OS APIs directly, whole classes of malicious operations are impossible.
Just like C/C++ apps you have to download and install an AIR app.
True, though I must say, the process is far slicker than anything else I've seen. Once you have the AIR runtime, a properly coded web page can offer single-click installation of the application. By that I mean a single click to start the installation. The user then gets asked the standard sorts of questions about where and whether they want the app installed, plus an uncommon warning stating what the program is allowed to do. This is all managed by the AIR runtime, so an AIR app cannot suppress this warning.
On Linux in particular, this will be a big boon. All of the common ways to install a non-AIR app on Linux are more difficult than this, some of them prohibitively so to the average PC user.
Unlike a C/C++ app, the app must be signed
Yes, and this is a good thing. Current OSes treat code from crackers in Croatia with every bit as much credulity as code from the OS's own installation DVD. If we had pervasive code signing, many of today's security problems wouldn't exist.
It's easy to sign AIR apps, too. The process is clearly documented in the manual, and if you're using an IDE like Flex Builder or Aptana Studio, it walks you through the process, even generating the code signing key for you if you don't already have one. The downside is that using a self-signed certificate to sign your application results in an additional warning during installation, since there is no real trust possible in this situation. To suppress this warning, you have to go through the hassle and expense of getting a code-signing certificate from one of the big CAs, and AFAIK only Thawte/Verisign are 100% supported.
This isn't much different from the SSL problem, though, which anyone running a secure web server also has to go through. It's possible that if you get your code signing cert from the same people you get your SSL cert from, that one or the other of the certs will be easier to get. I can't say, since I get mine from different places.
you're warned on the installation dialog that the app can access your files.
Yes, currently there is no way around this. Adobe says that sometime in the future, you may be able to ask the AIR runtime to apply additional restrictions to the application in exchange for a friendlier installation. This is the kind of feature that falls out of a platform offering pervasive code signing, almost for free.
One hopes these lock-down options are available soon. I know my own AIR app hardly needs any of the native system access that AIR offers. It could get by with a lot of restrictions.
I wouldn't think Adobe has just thrown away the source portability. After all portable code is expensive to create in the first place, but once you're there it's pretty cheap to maintain portability
The *ix ports were last updated seven major versions ago. We're talking back in the days before Netscape Navigator here! X11R5 was the installed base, the X Athena Widgets were still considered useful, the Adobe widget set has changed several times, C++ is almost a different language now.... The world has changed.
Even if -- big if -- this code is still around and still compiles, no one would want the end result because it would look like a 1994 program. And yes, looks matter: most of the complaints about The Gimp are about its UI, not about its functionality. Keep in mind, we're talking about a program aimed at creative professionals here. They won't tolerate ugly tools when beautiful alternatives exist.
It took Adobe about a year past the public announcement of the Intel Macs to port from PPC on OS X. They didn't change APIs (Carbon is still Carbon on Intel), their code must already be endinanness-clean and x86 aware because it runs on Windows...yet still it took a year. Given that, how can a Linux port, which is an entirely different set of platform APIs, be easy?
You say that like you believe you deserve to buy these products at prices you like. This is capitalism: the market will bear these prices, so these are the prices they charge.
Those who can afford the Adobe Creative Suite often make enough on a single job to pay for their license. Sure, it'd be swell if the programs were all free, but I can point to several of the Creative Suite competitors that are still trying to catch up after years and years of development. Sometimes free software moves faster, sometimes paid does. In the case of creative software, it seems to me that paid software moves faster, and so produces the sharpest, most powerful tools.
If you can't or don't want to buy the Suite or elements thereof, several Adobe products now come in inexpensive versions with fewer features, but which suffice for most purposes.
As for free software, I use it daily, and both my personal occupations and the company I work for depend on it. I maintain a popular LGPL'd package. (No it's not a "creative" tool.) Free software is great, but it doesn't cover every need. Sometimes the best tool for the job is commercial. I wouldn't argue that all of the components of the Creative Suite are the "best tool" -- some are, some aren't -- but combined, it's an awesome force, well worth paying for if you make money using these tools.
this is 2004, Holmes. If you can't figure out how to get a client to update itself via the internet, consider going into an MIS field because you aren't cut out to be a programmer.
You evidently haven't written programs used in a big Windows LAN, where it's quite popular to lock down the client machine. The end user can't install new software. It all has to go through the IT department. In schools, IT is usually in a district office somewhere, and they visit the individual school only when absolutely necessary.
Yes, "ghost" tools are popular in such LANs, but you'd be surprised how much convincing it takes to get some IT departments to update the client image. We've had rollouts of necessary fixes delayed 6 months just because the IT department wasn't ready to change its common client image.
We've also got a Web-based version of the same app. We want it updated, we dial (or ssh) into the server, drop a tarball on it, and it's done.
There is no such thing as "boxed Cygwin". Back in the Cygwin 1.0 days (a year or two ago) there was a boxed CD for sale, but they never made enough money on it to justify making another release. This has come up on the mailing list before, and they say they have no plans for making another CD.
The link you point to is GNUpro for Linux; there is no Cygwin variant available.
Aside from finishing the PDC/BDC implementation, what else is needed for Samba to completely replace Redmond's implementations?
(You know, the Samba guys have done a wonderful job simply because I have to ask this question. Everything remaining is probably just niggling details.)
What, exactly is the compiler not compatible with? I give it C++ source code and it compiles it for me.
Yes, Red Hat's gcc 2.96 does seem to do that.:)
It generates perfectly ISO compatible code. It's not RedHat's fault the ISO spec is vague and underdefined.
There is no such thing as "ISO compatible [generated] code". The ISO C++ Standard doesn't specify anything about code generation, just what all the language constructs shall do.
Name manging, the main "problem" with these post-2.95.2-pre-3.0 gcc's, is not at all defined by the standard. It's usually considered a feature, because name mangling exposes implementation details of the compiler: for a linker to link code generated by two different C++ compilers, they'd have to do many things the same. Given that, what's the point of competition in compilers? If you nail down implementation details like these, you eventually end up with something like Java or C#.
So why is Red Hat okay on this issue? EGCS 1.1, GCC 2.95.2, GCC "2.96" and the eventual GCC 3.0 are all very different compilers with different internals. This isn't Red Hat's fault or the GCC's Steering Group's fault -- it's simply a fact of life in the few years past the final release of a complicated language standard like ISO Standard C++. If you want super-stable compilers, go use C or Smalltalk or Fortran. C++ is in flux at the moment, but hopefully for the last time in several years.
In Red Hat's further defense, I have to say I've not found any problems with the compiler, and in fact many serious old problems have been fixed in it. Yes, I now have to rebuild all my libraries so I can link them with code generated by the "2.96" compiler. Waaaah!:)
"POSIX" is a good start towards being a flavor of UNIX, but it's not enough.
Via its Interix purchase, Microsoft now has the technology to make Windows NT/2000 totally POSIX.1 and POSIX.2 compliant, complete with X Windows! A free alternative to that is Cygnus's Cygwin environment, which is a complete port of the GNU tools (POSIX.2), along with an API layer that translates POSIX.1 calls to Win32.
But just use a Windows NT box running Interix or Cygwin. It's obviously not Unix.
To be Unix, the following have to be true:
POSIX has to be the best way to get something done on that system. If you have Interix or Cygwin installed on your Windows NT box, you still don't spend a whole lot of time trying to find a POSIX tool where an equivalent native Win32 tool exists.
POSIX.1 and POSIX.2 don't cover issues like "changing a user's info in/etc/passwd". Despite the lack of a standard, all Unixes work similarly in this regard. But even if a Unix-like user info mechanism was emulated on my Windows NT/Cygwin box, I would still use NT's User Manager, if only because Windows NT has user features that don't have an direct analogue under Unix.
These guidelines might seem unnecessarily exclusionary. But, just look at other OSes with POSIX layers. I've already shot down Windows NT with addons, so what about BeOS and MacOS X? Both of these are/will be POSIX.1 and POSIX.2 compliant. But like the WinNT/Interix combo, they fail both the guidelines above.
In all these "POSIX-but-not-Unix" systems, the Unix functionality is secondary to the "native" functionality. Most of the time, there's another way to do something, a way that makes more sense on that system than the Unix way.
The chroot(2) system call lets you change a process's "root" directory.
This lets you set up a very limited set of programs and data files, and then force a process to use that instead of having access to the entire file system.
Why is this useful? Two reasons:
It's easier to secure a system when you're only dealing with a few binaries and configuration files. My home box has 200,000+ files on it: you think I've got them all properly secured? Heck no!
Sometimes you want to set up varying levels of protection: say, one level for the people you let telnet in, and another level for anonymous FTP users. In fact, all decent FTP daemons can chroot themselves. Have you ever FTP'd into a server and found/etc,/usr and other Unixy directories at the top level, but almost nothing in them? That's because the administrator has set up a chroot'd environment for anonymous FTP users.
I don't know what FreeBSD's jail(2) call adds, but that gives you a good idea of its base capabilities.
Slashdot Mirror
I've put serious learning time in on at least 5 different general-purpose 3D graphics packages, including Blender. Blender is, hands-down, the hardest to learn and use of any I've tried. It even beat out a hoary old beast from the late 90's I had to use for a course, which was chosen purely because it was ancient and therefore cheap.
There are those that use the excuse, "It's professional grade, and pros don't cry about difficult to use tools." Well, sorry, but that only flies when there are no alternatives. If there's only one tool that does Thing X and the tool sucks, well, a pro will grit his teeth and use it anyway. That's not the case in 3D modeling / animation / rendering software. We have an embarrassment of choices, and they span a wide range of cost, power, and ease of use. Unless "freeeeee" is your only important criterion, there are usually better options than Blender, at least as of 2.4x.
I will certainly be playing with this new 2.5 version. Maybe they're right. Maybe they've completely fixed it all, and I can get off the Cinema4D, modo and SketchUp upgrade treadmills.
Now everyone can make more humans. Oh, wait...
Commercial SSH has always just pretty much been for suckers...
That's probably true if you refer only to command line ssh.
For GUI SSH, however, spending a bit of coin can be very much worth it.
I have to use Windows on my work desktop, from which I help manage hundreds of remote Linux boxen. It would be madness to do that that with PuTTY, with its horrible UI, or with ssh in a Cygwin window, where session management is entirely missing, unless you count ~/.ssh/config. The commercial GUI SSH client we use[*] lets us organize all those sessions, save login info, and sync all that among the handful of computers used by the people who I help with those remote servers. A user name, password, or IP changes about once a week, somewhere. Managing that with just command line tools would be less efficient. Further, we get features like a tabbed UI, integrated file transfer, scripting, etc. We pay back our hundred bucks a seat in efficiency pretty quickly.
[*] no point naming it, I'm not here to sell anyone anything
"Very timidly"? Nonsense. You want an example of open source timidity, look at Microsoft: how many substantial open-source programs do they provide? By comparison, Sun was profligate. Oracle is a clear regression back along the continuum toward the Microsoft end.
The question in my mind is, does Oracle actually intend to regress like this, or are we just seeing the fallout of standard merger problems? Is this all just stemming from mismanagement, resource allocation battles, and general confusion, or is there a mandate from the top to regress?
how would they know how to find you.
If you're lost in the mountains, simply knowing which tower received the SMS message would probably help the SAR team a lot.
Besides, this would allow SAR to hold a slow IM-like conversation with the lost person. They could describe their surroundings, coordinate movements, give status updates, etc.
It would be nice if the FCC would also raise the cap on radio strength when sending messages to 911. It should be able to temporarily jump to, say, 5 W to burst the SMS out. Even if this is only one-way, it'd probably save a lot of lives.
He was a cult hero long before he began bashing on Powerpoint. That's just the thing he happens to be known for best now, probably because more people have to build Powerpoint presentations than have to design infographics.
If the 35S I bought a few months ago is any indication, they're back on the right path. They're not the same as the 1990's and earlier generation HPs I have, but they suck a lot less.
I hear the 50G is part of this return to high build quality standards, but I haven't tried one myself.
No, actually, it won't. Read this: http://queue.acm.org/detail.cfm?id=1773943
Sure, but the ping time is a real bitch.
Sure, it'll suck down a lot of power, which is why I don't use mine as a server. I use it as a secondary desktop, so it can sleep most of the day away. It's absolutely fine for that. Only use that G5 as a server if you can actually keep the thing busy most of the time.
You can keep your clocks accurate with something that isn't inherently unstable and complex, like RADclock. Or for leaf nodes, you can stay with the same basic protocol but jettison a lot of the complexity by switching to SNTP.
The problem with DocBook XML + MathML is that most DocBook processors (i.e. XML-FO formatters) don't support MathML. I'm only aware of one XML-FO processor that will do this, AntennaHouse's XSL Formatter with the MathML add-on. Versions of this start at $400, which isn't horrible considering what it does.
With only one choice, you have to take the whole bag of features as a whole, or lose out on MathML. I bought a formatter from one of AntennaHouse's competitors because I needed some of its features more than I needed MathML support. I ended up hacking a GNU make based system to format the equations in LaTeX form to both PDF and GIF formats, which I then included as illustrations in the DocBook document. (The PDF equations get included in the PDF version of the final document, and the GIFs get included in the HTML version.) It's a fairly ugly hack, but the resulting document looks nice, so I'll live with it.
What this discovery does is completes the set of possible passive devices; we've found them all now, there will be no more. Everything else you're talking about are active devices, which I would argue cannot be reduced to a fundamental set.
To contrast the two, let's think about how we would define the fundamental set of semiconducting active devices. The simplest is a diode: it's just a PN junction. Everything else is made of different arrangements of P and N material, plus insulators. A bipolar transistor is a PNP or NPN arrangement, and there are two ways to run one "backwards" and get a diode, one using a PN path, the other NP. But you can't just solder a pair of discrete diodes together and get a bipolar transistor; the physical arrangement of the materials matters. And if arrangement of materials matters, is a FET fundamental, or is it just part of the class of devices called "transistors"? Where do UJTs, SCRs, triacs, and IGBTs fit? I say these are all variations on a theme with infinite possibilities. It's like with music: you can't draw a line around certain sounds and say "those within are musical notes, and those without are not".
By contrast, the set of passives is a fixed-size set, with each element being completely unlike any other. An ideal inductor has no capacitance and no resistance; an ideal resistor has no capacitance or inductance; and an ideal capacitor has no resistance or inductance. (Real ones have parasitic elements of the others, but there's no fundamental mathematical requirement for this.) We can draw a line around this set and say, "this is fundamental, all passive circuits are built on these elements".
Secure software that works online and offline, on your choice of the three major client OSes.
Okay, let me try to explain it.
.NET, Python, Perl, modern web browsers...you name it. The only thing more powerful is native code.
First, consider Flash itself. It started as an animation tool, but in the past few releases, it's gained a lot of application development power. It's now on par with every modern development environment from a pure capability standpoint: Java,
Even if you're a software developer, you probably didn't know that because the Flash authoring environment is a horrid way to write a typical program. Its source code editing facilities are nearly as poor as using Notepad, and the environment's architecture centers on the timeline and drawing tools. For a code-heavy project, it's the wrong tool for the job. Software developers ignore it, and rightly so.
Enter Flex Builder. This is an Eclipse-based IDE for working with ActionScript code and compiling it to Flash SWF files. Anything you can build in the Flash authoring environment, you can do in Flex Builder, but the weaknesses and strengths are inverted: it's great for code heavy projects, poor for ones heavy on the graphics and animation. It also includes the Flex application framework, which offers all the typical facilities you find in other application frameworks: GUI controls, network I/O mechanisms, file I/O, XML parsing, database interaction... Plus, everything available in the Flash ActionScript API is there, too.
All of this has existed for years now. What's new are AIR, and the open sourcing of the Flex framework and command-line tools.
Flex applications run in a web browser, using the Flash plugin for that browser. The AIR runtime includes enough of a web browser to support the Flash plugin and Flex applications, plus some new APIs for local filesystem access, printing, etc. Basically, it lets a Flex app break free from the web browser, and provides enough additional facilities to make it worthwhile to do so.
The Flex framework and command line tools let you build your own development environment to replace Flex Builder. You can now build Flex applications with any text editor, and build system you like. Rather use vi than Eclipse? Now you can. Want to hack on the tools themselves, rather than build applications? Go ahead. All Adobe is keeping for themselves now is the runtime; this seems sensible to me given the history of competing runtime environments. (Write once, debug everywhere.) Adobe also has the standard development environments, but they've given the world all the tools they need to compete directly.
If you want to get a sense of what Flex is capable of, see Adobe's own flagship demo applications. I recommend Kuler, Photoshop Express, and Buzzword. I don't believe any of these have compelling AIR versions yet, but to imagine the AIR version, just imagine that you can run any of these without a web browser, and without being connected to the Internet. It's that seamless a transition from a Flex app to an AIR app.
Yes, some malicious possibilities exist, mostly stemming from the fact that AIR lets you access the local file system with the full permissions of the user running the app. As long as the file system is reasonably secured, though, the maximum damage should be limited to user files only. Because the runtime doesn't let AIR apps call OS APIs directly, whole classes of malicious operations are impossible.
True, though I must say, the process is far slicker than anything else I've seen. Once you have the AIR runtime, a properly coded web page can offer single-click installation of the application. By that I mean a single click to start the installation. The user then gets asked the standard sorts of questions about where and whether they want the app installed, plus an uncommon warning stating what the program is allowed to do. This is all managed by the AIR runtime, so an AIR app cannot suppress this warning.
On Linux in particular, this will be a big boon. All of the common ways to install a non-AIR app on Linux are more difficult than this, some of them prohibitively so to the average PC user.
Yes, and this is a good thing. Current OSes treat code from crackers in Croatia with every bit as much credulity as code from the OS's own installation DVD. If we had pervasive code signing, many of today's security problems wouldn't exist.
It's easy to sign AIR apps, too. The process is clearly documented in the manual, and if you're using an IDE like Flex Builder or Aptana Studio, it walks you through the process, even generating the code signing key for you if you don't already have one. The downside is that using a self-signed certificate to sign your application results in an additional warning during installation, since there is no real trust possible in this situation. To suppress this warning, you have to go through the hassle and expense of getting a code-signing certificate from one of the big CAs, and AFAIK only Thawte/Verisign are 100% supported.
This isn't much different from the SSL problem, though, which anyone running a secure web server also has to go through. It's possible that if you get your code signing cert from the same people you get your SSL cert from, that one or the other of the certs will be easier to get. I can't say, since I get mine from different places.
Yes, currently there is no way around this. Adobe says that sometime in the future, you may be able to ask the AIR runtime to apply additional restrictions to the application in exchange for a friendlier installation. This is the kind of feature that falls out of a platform offering pervasive code signing, almost for free.
One hopes these lock-down options are available soon. I know my own AIR app hardly needs any of the native system access that AIR offers. It could get by with a lot of restrictions.
The *ix ports were last updated seven major versions ago. We're talking back in the days before Netscape Navigator here! X11R5 was the installed base, the X Athena Widgets were still considered useful, the Adobe widget set has changed several times, C++ is almost a different language now.... The world has changed.
Even if -- big if -- this code is still around and still compiles, no one would want the end result because it would look like a 1994 program. And yes, looks matter: most of the complaints about The Gimp are about its UI, not about its functionality. Keep in mind, we're talking about a program aimed at creative professionals here. They won't tolerate ugly tools when beautiful alternatives exist.
It took Adobe about a year past the public announcement of the Intel Macs to port from PPC on OS X. They didn't change APIs (Carbon is still Carbon on Intel), their code must already be endinanness-clean and x86 aware because it runs on Windows...yet still it took a year. Given that, how can a Linux port, which is an entirely different set of platform APIs, be easy?
You say that like you believe you deserve to buy these products at prices you like. This is capitalism: the market will bear these prices, so these are the prices they charge.
Those who can afford the Adobe Creative Suite often make enough on a single job to pay for their license. Sure, it'd be swell if the programs were all free, but I can point to several of the Creative Suite competitors that are still trying to catch up after years and years of development. Sometimes free software moves faster, sometimes paid does. In the case of creative software, it seems to me that paid software moves faster, and so produces the sharpest, most powerful tools.
If you can't or don't want to buy the Suite or elements thereof, several Adobe products now come in inexpensive versions with fewer features, but which suffice for most purposes.
As for free software, I use it daily, and both my personal occupations and the company I work for depend on it. I maintain a popular LGPL'd package. (No it's not a "creative" tool.) Free software is great, but it doesn't cover every need. Sometimes the best tool for the job is commercial. I wouldn't argue that all of the components of the Creative Suite are the "best tool" -- some are, some aren't -- but combined, it's an awesome force, well worth paying for if you make money using these tools.
You evidently haven't written programs used in a big Windows LAN, where it's quite popular to lock down the client machine. The end user can't install new software. It all has to go through the IT department. In schools, IT is usually in a district office somewhere, and they visit the individual school only when absolutely necessary.
Yes, "ghost" tools are popular in such LANs, but you'd be surprised how much convincing it takes to get some IT departments to update the client image. We've had rollouts of necessary fixes delayed 6 months just because the IT department wasn't ready to change its common client image.
We've also got a Web-based version of the same app. We want it updated, we dial (or ssh) into the server, drop a tarball on it, and it's done.
This Treo has more MHz than my first five computers combined.
There is no such thing as "boxed Cygwin". Back in the Cygwin 1.0 days (a year or two ago) there was a boxed CD for sale, but they never made enough money on it to justify making another release. This has come up on the mailing list before, and they say they have no plans for making another CD.
The link you point to is GNUpro for Linux; there is no Cygwin variant available.
(You know, the Samba guys have done a wonderful job simply because I have to ask this question. Everything remaining is probably just niggling details.)
--
What, exactly is the compiler not compatible with? I give it C++ source code and it compiles it for me.
Yes, Red Hat's gcc 2.96 does seem to do that. :)
It generates perfectly ISO compatible code. It's not RedHat's fault the ISO spec is vague and underdefined.
There is no such thing as "ISO compatible [generated] code". The ISO C++ Standard doesn't specify anything about code generation, just what all the language constructs shall do.
Name manging, the main "problem" with these post-2.95.2-pre-3.0 gcc's, is not at all defined by the standard. It's usually considered a feature, because name mangling exposes implementation details of the compiler: for a linker to link code generated by two different C++ compilers, they'd have to do many things the same. Given that, what's the point of competition in compilers? If you nail down implementation details like these, you eventually end up with something like Java or C#.
So why is Red Hat okay on this issue? EGCS 1.1, GCC 2.95.2, GCC "2.96" and the eventual GCC 3.0 are all very different compilers with different internals. This isn't Red Hat's fault or the GCC's Steering Group's fault -- it's simply a fact of life in the few years past the final release of a complicated language standard like ISO Standard C++. If you want super-stable compilers, go use C or Smalltalk or Fortran. C++ is in flux at the moment, but hopefully for the last time in several years.
In Red Hat's further defense, I have to say I've not found any problems with the compiler, and in fact many serious old problems have been fixed in it. Yes, I now have to rebuild all my libraries so I can link them with code generated by the "2.96" compiler. Waaaah! :)
--
Via its Interix purchase, Microsoft now has the technology to make Windows NT/2000 totally POSIX.1 and POSIX.2 compliant, complete with X Windows! A free alternative to that is Cygnus's Cygwin environment, which is a complete port of the GNU tools (POSIX.2), along with an API layer that translates POSIX.1 calls to Win32.
But just use a Windows NT box running Interix or Cygwin. It's obviously not Unix.
To be Unix, the following have to be true:
- POSIX has to be the best way to get something done on that system. If you have Interix or Cygwin installed on your Windows NT box, you still don't spend a whole lot of time trying to find a POSIX tool where an equivalent native Win32 tool exists.
- POSIX.1 and POSIX.2 don't cover issues like "changing a user's info in
/etc/passwd". Despite the lack of a standard, all Unixes work similarly in this regard. But even if a Unix-like user info mechanism was emulated on my Windows NT/Cygwin box, I would still use NT's User Manager, if only because Windows NT has user features that don't have an direct analogue under Unix.
These guidelines might seem unnecessarily exclusionary. But, just look at other OSes with POSIX layers. I've already shot down Windows NT with addons, so what about BeOS and MacOS X? Both of these are/will be POSIX.1 and POSIX.2 compliant. But like the WinNT/Interix combo, they fail both the guidelines above.In all these "POSIX-but-not-Unix" systems, the Unix functionality is secondary to the "native" functionality. Most of the time, there's another way to do something, a way that makes more sense on that system than the Unix way.
--
This lets you set up a very limited set of programs and data files, and then force a process to use that instead of having access to the entire file system.
Why is this useful? Two reasons:
- It's easier to secure a system when you're only dealing with a few binaries and configuration files. My home box has 200,000+ files on it: you think I've got them all properly secured? Heck no!
- Sometimes you want to set up varying levels of protection: say, one level for the people you let telnet in, and another level for anonymous FTP users. In fact, all decent FTP daemons can chroot themselves. Have you ever FTP'd into a server and found
/etc, /usr and other Unixy directories at the top level, but almost nothing in them? That's because the administrator has set up a chroot'd environment for anonymous FTP users.
I don't know what FreeBSD's jail(2) call adds, but that gives you a good idea of its base capabilities.--