My guess? It's probably to make an iPhone development kit for Windows possible. iPhone (and future iPod) development will be based widgets (webkit). If it were not possible from Windows, many developers would unable to do anything with it. And perhaps Apple is going to connect Safari and the iPhone somehow?
Insightful? I'm not sure how "sucks hard on the desktop" is insightful. We have several developers (and a few office staff) here who have used Fedora for a few years now, and we've had a very good time of it. It works well for us, our clients, and many of the people we know.
Do you perhaps have some insightful reasons why it sucks so hard?
It's not just a string, it's a series of blocks that can be read as ASCII or binary data (for most tags/readers). The data can be encrypted, and the blocks can be locked (to become read-only permanently). And the applications can be smart enough, if they do not lock/encrypt the tags, to consider the data more clearly.
Web apps are *already* taking over for desktop apps. Not all of them, and the applications themselves are very different. But, that doesn't change the fact that most of my daily-use applications are now web apps.
Where do I start?
Search. Ten years ago I used the web regularly. I collected bookmarks in my browser, using a set of search scripts I ran on my local machine. Today, I don't bother with many bookmarks, and I collect all of my bookmarks using web-based tools, or not at all (most things I an find effortlessly using simple Google searches). Most of my information-based uses of my PC have moved entirely online.
Works like a hot-damn too.
News. Ten years ago, most of my news-like reading was done in a news reader. Today, I use Bloglines (and RSS). It's better than any client-side tool I've used, as it offloads the aggregation work for many thousands of users.
Writing. Most of my writing ten years ago was done in client-side applications. Today, all of my trivial rants, and shorter articles are written in web applications. What used to require Word (or similar) is now done using non-rich web applications. Richer web writing tools will only solidify this trend.
Finances. Ten years ago I used a rich-client tool for managing my finances. Today, my bank provides a tool for tracking all of my finances. I can see, and reconcile, all of my expendetures, and plan/execute improved payment schedules.
Taxes. Ten years ago I did all of my taxes by-hand, and later paid some bozo to do it for me. Now, I use an online service, uFile.ca, which allows me to do my taxes online. It's better than any client-side tool I've seen, and it makes better recommendations than my bozo accountants did.
Games. Most of the trivial games I play these days are either online, or on my GameCube. I don't bother with the larger PC games anymore, as I've outgrown the retarded hardware race. This allows me to use the same PC for many years.
There are applications that can't be done well online yet, but they're quickly disappearing. The new applications aren't exact analogs, of course, which makes it harder to see the transition. But, most of my uses of computers are now strongly related to things that don't run on my local machine.
In our small office, we have cut costs by factoring out un-needed servers. When I started there a year ago, there were 30+ servers running in a cooled server room. They had a OC3, and were hosting their own mail, web, dns, etc.
Now we have 4 servers running internally, and one running offsite. We pay a hosting company to manage our mail and web services, which costs us 1/4 of what we paid our own staff to do. We've dropped our fiber and use business DSL, which is another large savings. We also order all of our equipment from a very capable local shop, who take care of building and configuring hardware for us. As a bonus, or local retailer serves as our expert on hardware choices.
A side-benifit of reducing the number of servers we use, we have a surplus of spare parts. These changes also allow IT staff to be redistributed in the company, doing more important things (like testing, customer support, development). While we still order new parts, we've been able to drop our hardware budget by more than half for the past year.
Resources are better spent on things related to your products and services, so it's important to spend your people on those things as well... and not on IT. IT, in many ways, is like plumbing or electrical: the business does well to have the services, but should not feel they need to do it all themselves. Stick to the domain of the business.
You could restrict which sites are allowed to display ActiveX controls, and restrict which controls on a given page are loaded. Offer the option of displaying a page's ActiveX controls: if users can download a Win32 exe and subsequently run it, they should be able to selectively run ActiveX controls.
Another possibility is to execute ActiveX controls in a Wine sandbox.
There are always many possibilities, some of them even sensible.
Active X is the worst security model anyone could think of.
Do you happen to know what the security model is? FWIW, it's not the worst security model out there. It's flawed, but to say that it's the worst is a typical Slashdot exageration.
It may be possible to support ActiveX from Mozilla with added security for example, which would improve on the flaws in the IE implementation. Now that would be A Good Thing.
I actually had a much different experience, but it was at a children's hospital that was also used for training. The doctors there worked with us (the parents), as if we were part of their team. There were at least a dozen doctors, and each of them would walk us through test results, and didn't ignore the "what about {n}?" questions, to the point that new tests were ordered when things appeared to be missing.
As the doctors were baffled by his condition, they were open to our suggestions and ideas. We were even able to review his chart (and ask questions) whenever we wanted (which is a lot different than most adult-hospitals I've been to).
What impressed me was the huge set of possibilities that the doctors had to consider in their decision tree. Minute facts about our son's case would shift the tree significantly, and the doctors were able to handle this large data set (and the changes) with ease. Their domain is many times more complex than software development, based on the size of the data, the quality of tools, and the integrity of the data logging (people tell many stories). Even better, these doctors were able to make me feel like an equal in a very difficult situation. That in itself is a hard problem.
Over the course of our son's time in the hospital, his condition was characterized in 3 ways. The first two didn't sit well with us, as we had experienced his episodes (heart attacks) first-hand. The doctors trusted us that the diagnosis didn't seem to fit the experience, and they persisted in asking us questions, and analysing the test results until something fit. It was amazing.
I've had other hospital experiences that were much worse, but the good ones are out there.
You're not the only one, but I suspect that the people who love it don't waste their time answering whiners here at slashdot. I usually refuse to jump into the pointless "$project sucks" conversations, as they're pointless and poorly argued..
That said, I've loved the direction Gnome has taken in the last few years. It runs well on my slow machines (600mhz/256/nv), and even better on my desktop machines (2Ghz+). It looks good, it's simple, and the simplicity is well placed. They're doing all the right things, and they know it. Even spacial nautilus is A GOOD DAMNED thing, even for old hacks like myself. Every single release has been better than the last, and I'm productive and enjoy every moment.
For those who don't like Gnome 2.x or any other project: help fix it, fork it, or shut it up and use something else.
Scripting languages, like Python, *are* generally more productive than C, C++, or Assembly code. But productivity isn't always the most important axis of a project, and when it's not, there is likely a language to fit your needs. And some things are a terrible fit for a scripting language. In the case of the parent topic, GUI applications of nearly any size fit Python reasonably, and there are several good examples out there (Straw off the top of my head).
To tie this to the topic: "...that Python without a decent IDE is definitely not easier to use than C++ with an IDE.", the premise that the IDE is somehow a precurser to productivity is a narrow view. I'm trying to encourage the poster to widen their view, as there is a lot of productivity to be found in many tools, and many languages -- as they fit the problem.
I bash on the IDE mindset because it's so blindly followed. IDEs are not bad, but believing that they are somehow new, wonderful, or magical is misled. Emacs is a powerful IDE, just as Gnu/Linux is, or Windows with the MSDN. The key is that we need to keep our eyes open, as there is a lot of neat shit out there if you're looking.
Python, in particular, doesn't really need a kick-ass IDE to be a productive for building serious apps. Python, bash, Glade, and your text editor of choice is a very productive set of tools (an IDE if you use your immagination), as good as the Visual Studio (for VB or C#).
Yes, I know they exist... and yes, I use IDEs. IDEs are just tools, and they're not the only tools out there. Limiting your toolkit to one large hammer is just plain nuts, as the more you know, the more useful you can be. There's a whole world of tools out there that people are ignoring, because they think they need an IDE.
You seriously think production shops use Visual Studio as their production build system? Most shops use it as their editor, and their GUI builder, but production builds usually go through something like Visual Build. Why? The build tools in Visual Studio are suited to a smaller set of problems. That's not a bad thing.
The point is that THERE ARE OTHER TOOLS. Remember that every tool is integrated into the operating system, so why limit yourself to tools integrated with your editor/RAD environment? When you realize your OS can be your IDE, then you'll find there are more tools you can pick from to do your work for you.
I think you might be missing out on some of the most important features of Python (or any decent scripting language these days): it's a high level lanugage, intended to be easier to use than lower-level languages like C/C++. Whining about a lack of GUIs is besides the point.
Once you know Python, and understand some of the GUI toolkits, it's far more productive than C/C++ with similar toolkits. So is Perl, Java, or C# for that matter. It sounds like you don't know Python and related GUI toolkits very well yet, though, which is one place where an IDE can be used to limp along for a while.
In case you haven't noticed, an IDE is really a simple set of tools, which exist for nearly every language already -- though not always packaged together. Get over it: your best toolkits won't come in one package, ever. Any good craftsman will learn to piece together a master's toolkit for any problem set, and use those tools when/where appropriate. IDEs, in general, are the Walmart AllInOne toolkit. Okay if you don't know any better, and the problems are small, but not often suited for anything of scale. Think I'm being a twit? How many IDEs are used in production build environments? (Hint: none)
So back to your baseless productivity point: Python is more productive, in general, than C/C++. This includes GUI work without an IDE, and a lot of server problems that are usually mashed into using C/C++. Why? The language (and libraries) focus on ease of use... and are not encumbered by aspects of the underlying hardware leaking through the abstractions. Things like direct memory access, pointers, and references have their place, but are the root of a large amount of debugging time. GUIs in the lower-level languages waste a lot of time with low-level bugs (though there is a chance that performance will be better).
GUI work without a GUI builder you say? If it's too tedious for you, then automate it (Python happens to be really handy for that). Most GUIs are built around schemas or specifications anyways -- using a GUI builder only speeds up the tedium (it doesn't solve it). And you'll want to know the GUI toolkit well enough to automate with it anyway (using it in ignorance with a GUI builder is buggy in itself). Don't get me wrong, there are some great GUI builders for Python, but don't rely on it to save you from learning something.
One of the best IDEs I've found (and I've used a lot of IDEs) is the OS, and tangent language tools themselves. For Perl, I use Vi, Gedit, or Textpad for my editor, GladeXML or perl scripts to generate UIs, bash/MakeMaker for my build system, and the other Unix tools to fill in the gaps. I've used some of the Perl IDEs in production environments, and they're all limited somewhere. Don't settle for one tool, as your tools contribute to the quality/quantity of what you produce. You can be in control.
Google almost does topic-searches, try:
~"TCP/IP tutorials"
Which attempts to do a synonym-search, which is darned close to a topic search (in the way that I use it anyway).
I'm actually surprised that someone hasn't marketed this before. Last year while building an embedded system with Embedded XP, we built a few bootable XP CDs with various levels of the OS. A few years before that we did the same thing with 2000. And before that we had done it with NT too. We found that the CDs were a simple way to test our platform, without writing an eprom (or later to a DOC). We had no interest in marketing it as they were working in a vertical marketn (weren't interested in mass-marketing).
One thing that I've noticed, since I started using Gnu systems, is that it's like the good-old-days again -- just like the nostalgia of reading these old kid's programming books. Using the shell, and great languages like python and perl, has the same flavour, and freedoms that I enjoyed on my Atari 800 (and each subsequent box).
Maybe it's the availability of many, small, free programs -- which is a contrast to the windows pay-for-every-crappy-utility world. Maybe it's the large number of similar historied geeks that have created this free world, or maybe it's just my imagination. For big kids, anyway, the HOWTOs and other online gold are the next generation of our great past.
Uh, gtk is object based in case you haven't noticed. Just because it's written in C doesn't mean it can't use objects. Gtk+ allows for very decent subclassing, as does the plain-old-C Win32 GUI Apis for that matter, though I personally find the Gtk+ approach much cleaner (they've taken the time to develop a very clean API).
The only 'bloat' in Gtk+ may be in the infrastructure required to support C-style objects, but it does give one distinct advantage over using pure C++ (or Java) for the widget set: complete (and absolute) control. Notice what Trolltech has done with their QT widgets with the signal/slot pre-compilation process (they had to work around a limitation of the language), this is a decent approach but shows a minor limitation of the toolkit language. I think that QT is a great OO-style toolkit, as is Gtk+.
Try Typepad... it's a pay-for service, but it's damned simple to use. I was a second-round beta tester, and I found it one of the easiest web-publishing software out there, as did the hundreds of other beta-testers I talked with. It's an updated version of MoveableType (which is also very good), but simplified for the average shmoe. It even includes a handy 'layout' editor, which allows the sort of page customization most people want, without *any* understanding of how the stuff actually works. Everything is simple, grokable, and does what it can to hide the technical details. It even has nifty features that auto-link amazon images to your posts and stuff. Safe for the whole family.
I've used most everything else over the last 10+ years: slashcode, phpnuke, pyblosxom, blosxom, moveabletype, citydesk, blogger... and none of it was shmoe-worthy. It was all geek-worthy, but the many technical details dumbfounded the non-techs I know.
Note, I run my sites using blosxom, ssh, vi, and make... but then again, I'm not normal people.
We've also heard, from within Samsung, that they will be producing Alphas for some time. But, at the same time, they seem to be migrating their internal IT use of Alpha to other platforms (lack of OS Vendor support).
My experience with Alpha development is only so-so. A great architecture, and a solid OS, but porting to it was almost as painful as HPuX -- for C++ at least. That really taught us a lesson, too, that C++ portability is still way back there. We found the same with Java too, at least on Alpha (the 1.4 JVM was in beta for more than year after it was released on windows).
Best is always arguable;-) Both VIM and Emacs, though, are incredible code-editors, and are mature, feature-rich, and fun. VIM and Emacs are not toys, they are heavy-duty tools... hence the not-so-lean-learning-curve.
There are *hundreds* of free text editors for GNU/Linux though, some of which are incredibly easy to use. Gedit, Scintilla, Glimmer, Anjuta, Pico, Nano, Jed are a few I can think of off the top of my head. The free Java editors work well too (Jedit, etc.).
I was thinking about this problem the other day, as it relates to open-source game development. One of the main problems with small-scale game development is the creation of content (it's a lot of effort), and algorithmic content would make it easier for a smaller-group of developers to build a good game.
But a problem with random content is that it can suck, like impossible nethack levels, etc., as the algorithms have no great sense of athstetics or any of the other abilities require to make 'good' levels. Designing algorithms to test for athstetics is also difficult, and probably only worth doing for a few cases.
The conclusing I came to was that algorithms could be used to pre-generate content (like maps, etc), in the sense of the "millions-of-monkeys" problem, except with a bit of focus. Algorithms would generate content (maps, shapes, etc.), and then the work would be filtered by the developers, and the good stuff made part of the game. The algorithms could also use some sort of learning to improve the generation process, similar to spam filtering - "this is spam" vs. "this is not spam" user-initiated filter improvement.
This sort of approach would really make small-shop game development easier, as would improving (and standardizing) content-production tools and processes.
You might try an Arm processor, many of which have great built-in features (like NIC, daq, memory management). You can get demoboards, and run linux + related gnu tools on them. ARM-based systems make great embedded/distributed systems (aka 'the future'), and are a useful to learn for the old-resume.
You think a process will make OSS better? The act of defining a process renders it useless, as the principles become static. Software will only get better when we do away with processes. Software is complex, it requires us to think -- not follow procedures.
I've been a part of many small and large processes, and none of them were effective. The best any of them were able to do was to soften what was produced by the morons. In lessening the effect of retarded developers, the processes become a hindering block to those who know wtf they are doing. Process is so fun.
Software development needs to be organic. OSS needs more mentors, gurus of the deep, dark, unknown to become one with the new blood. It is about community, and about collaboration - the real sort of kinship where people build things together. Process is about as un-personal as it gets.
Slashdot Mirror
You're insane. You don't have to cave in: it's always your fucking choice.
My guess? It's probably to make an iPhone development kit for Windows possible. iPhone (and future iPod) development will be based widgets (webkit). If it were not possible from Windows, many developers would unable to do anything with it. And perhaps Apple is going to connect Safari and the iPhone somehow?
Insightful? I'm not sure how "sucks hard on the desktop" is insightful. We have several developers (and a few office staff) here who have used Fedora for a few years now, and we've had a very good time of it. It works well for us, our clients, and many of the people we know.
Do you perhaps have some insightful reasons why it sucks so hard?
It's not just a string, it's a series of blocks that can be read as ASCII or binary data (for most tags/readers). The data can be encrypted, and the blocks can be locked (to become read-only permanently). And the applications can be smart enough, if they do not lock/encrypt the tags, to consider the data more clearly.
It's obvious that you're on the crack.
Web apps are *already* taking over for desktop apps. Not all of them, and the applications themselves are very different. But, that doesn't change the fact that most of my daily-use applications are now web apps.
Where do I start?
Search. Ten years ago I used the web regularly. I collected bookmarks in my browser, using a set of search scripts I ran on my local machine. Today, I don't bother with many bookmarks, and I collect all of my bookmarks using web-based tools, or not at all (most things I an find effortlessly using simple Google searches). Most of my information-based uses of my PC have moved entirely online.
Works like a hot-damn too.
News. Ten years ago, most of my news-like reading was done in a news reader. Today, I use Bloglines (and RSS). It's better than any client-side tool I've used, as it offloads the aggregation work for many thousands of users.
Writing. Most of my writing ten years ago was done in client-side applications. Today, all of my trivial rants, and shorter articles are written in web applications. What used to require Word (or similar) is now done using non-rich web applications. Richer web writing tools will only solidify this trend.
Finances. Ten years ago I used a rich-client tool for managing my finances. Today, my bank provides a tool for tracking all of my finances. I can see, and reconcile, all of my expendetures, and plan/execute improved payment schedules.
Taxes. Ten years ago I did all of my taxes by-hand, and later paid some bozo to do it for me. Now, I use an online service, uFile.ca, which allows me to do my taxes online. It's better than any client-side tool I've seen, and it makes better recommendations than my bozo accountants did.
Games. Most of the trivial games I play these days are either online, or on my GameCube. I don't bother with the larger PC games anymore, as I've outgrown the retarded hardware race. This allows me to use the same PC for many years.
There are applications that can't be done well online yet, but they're quickly disappearing. The new applications aren't exact analogs, of course, which makes it harder to see the transition. But, most of my uses of computers are now strongly related to things that don't run on my local machine.
In our small office, we have cut costs by factoring out un-needed servers. When I started there a year ago, there were 30+ servers running in a cooled server room. They had a OC3, and were hosting their own mail, web, dns, etc.
... and not on IT. IT, in many ways, is like plumbing or electrical: the business does well to have the services, but should not feel they need to do it all themselves. Stick to the domain of the business.
Now we have 4 servers running internally, and one running offsite. We pay a hosting company to manage our mail and web services, which costs us 1/4 of what we paid our own staff to do. We've dropped our fiber and use business DSL, which is another large savings. We also order all of our equipment from a very capable local shop, who take care of building and configuring hardware for us. As a bonus, or local retailer serves as our expert on hardware choices.
A side-benifit of reducing the number of servers we use, we have a surplus of spare parts. These changes also allow IT staff to be redistributed in the company, doing more important things (like testing, customer support, development). While we still order new parts, we've been able to drop our hardware budget by more than half for the past year.
Resources are better spent on things related to your products and services, so it's important to spend your people on those things as well
You could restrict which sites are allowed to display ActiveX controls, and restrict which controls on a given page are loaded. Offer the option of displaying a page's ActiveX controls: if users can download a Win32 exe and subsequently run it, they should be able to selectively run ActiveX controls.
Another possibility is to execute ActiveX controls in a Wine sandbox.
There are always many possibilities, some of them even sensible.
Do you happen to know what the security model is? FWIW, it's not the worst security model out there. It's flawed, but to say that it's the worst is a typical Slashdot exageration.
It may be possible to support ActiveX from Mozilla with added security for example, which would improve on the flaws in the IE implementation. Now that would be A Good Thing.
I actually had a much different experience, but it was at a children's hospital that was also used for training. The doctors there worked with us (the parents), as if we were part of their team. There were at least a dozen doctors, and each of them would walk us through test results, and didn't ignore the "what about {n}?" questions, to the point that new tests were ordered when things appeared to be missing.
As the doctors were baffled by his condition, they were open to our suggestions and ideas. We were even able to review his chart (and ask questions) whenever we wanted (which is a lot different than most adult-hospitals I've been to).
What impressed me was the huge set of possibilities that the doctors had to consider in their decision tree. Minute facts about our son's case would shift the tree significantly, and the doctors were able to handle this large data set (and the changes) with ease. Their domain is many times more complex than software development, based on the size of the data, the quality of tools, and the integrity of the data logging (people tell many stories). Even better, these doctors were able to make me feel like an equal in a very difficult situation. That in itself is a hard problem.
Over the course of our son's time in the hospital, his condition was characterized in 3 ways. The first two didn't sit well with us, as we had experienced his episodes (heart attacks) first-hand. The doctors trusted us that the diagnosis didn't seem to fit the experience, and they persisted in asking us questions, and analysing the test results until something fit. It was amazing.
I've had other hospital experiences that were much worse, but the good ones are out there.
You're not the only one, but I suspect that the people who love it don't waste their time answering whiners here at slashdot. I usually refuse to jump into the pointless "$project sucks" conversations, as they're pointless and poorly argued ..
That said, I've loved the direction Gnome has taken in the last few years. It runs well on my slow machines (600mhz/256/nv), and even better on my desktop machines (2Ghz+). It looks good, it's simple, and the simplicity is well placed. They're doing all the right things, and they know it. Even spacial nautilus is A GOOD DAMNED thing, even for old hacks like myself. Every single release has been better than the last, and I'm productive and enjoy every moment.
For those who don't like Gnome 2.x or any other project: help fix it, fork it, or shut it up and use something else.
Scripting languages, like Python, *are* generally more productive than C, C++, or Assembly code. But productivity isn't always the most important axis of a project, and when it's not, there is likely a language to fit your needs. And some things are a terrible fit for a scripting language. In the case of the parent topic, GUI applications of nearly any size fit Python reasonably, and there are several good examples out there (Straw off the top of my head).
To tie this to the topic: "...that Python without a decent IDE is definitely not easier to use than C++ with an IDE.", the premise that the IDE is somehow a precurser to productivity is a narrow view. I'm trying to encourage the poster to widen their view, as there is a lot of productivity to be found in many tools, and many languages -- as they fit the problem.
I bash on the IDE mindset because it's so blindly followed. IDEs are not bad, but believing that they are somehow new, wonderful, or magical is misled. Emacs is a powerful IDE, just as Gnu/Linux is, or Windows with the MSDN. The key is that we need to keep our eyes open, as there is a lot of neat shit out there if you're looking.
Python, in particular, doesn't really need a kick-ass IDE to be a productive for building serious apps. Python, bash, Glade, and your text editor of choice is a very productive set of tools (an IDE if you use your immagination), as good as the Visual Studio (for VB or C#).
Yes, I know they exist ... and yes, I use IDEs. IDEs are just tools, and they're not the only tools out there. Limiting your toolkit to one large hammer is just plain nuts, as the more you know, the more useful you can be. There's a whole world of tools out there that people are ignoring, because they think they need an IDE.
You seriously think production shops use Visual Studio as their production build system? Most shops use it as their editor, and their GUI builder, but production builds usually go through something like Visual Build. Why? The build tools in Visual Studio are suited to a smaller set of problems. That's not a bad thing.
The point is that THERE ARE OTHER TOOLS. Remember that every tool is integrated into the operating system, so why limit yourself to tools integrated with your editor/RAD environment? When you realize your OS can be your IDE, then you'll find there are more tools you can pick from to do your work for you.
So C++ is easier than Python without an IDE?
... and are not encumbered by aspects of the underlying hardware leaking through the abstractions. Things like direct memory access, pointers, and references have their place, but are the root of a large amount of debugging time. GUIs in the lower-level languages waste a lot of time with low-level bugs (though there is a chance that performance will be better).
I think you might be missing out on some of the most important features of Python (or any decent scripting language these days): it's a high level lanugage, intended to be easier to use than lower-level languages like C/C++. Whining about a lack of GUIs is besides the point.
Once you know Python, and understand some of the GUI toolkits, it's far more productive than C/C++ with similar toolkits. So is Perl, Java, or C# for that matter. It sounds like you don't know Python and related GUI toolkits very well yet, though, which is one place where an IDE can be used to limp along for a while.
In case you haven't noticed, an IDE is really a simple set of tools, which exist for nearly every language already -- though not always packaged together. Get over it: your best toolkits won't come in one package, ever. Any good craftsman will learn to piece together a master's toolkit for any problem set, and use those tools when/where appropriate. IDEs, in general, are the Walmart AllInOne toolkit. Okay if you don't know any better, and the problems are small, but not often suited for anything of scale. Think I'm being a twit? How many IDEs are used in production build environments? (Hint: none)
So back to your baseless productivity point: Python is more productive, in general, than C/C++. This includes GUI work without an IDE, and a lot of server problems that are usually mashed into using C/C++. Why? The language (and libraries) focus on ease of use
GUI work without a GUI builder you say? If it's too tedious for you, then automate it (Python happens to be really handy for that). Most GUIs are built around schemas or specifications anyways -- using a GUI builder only speeds up the tedium (it doesn't solve it). And you'll want to know the GUI toolkit well enough to automate with it anyway (using it in ignorance with a GUI builder is buggy in itself). Don't get me wrong, there are some great GUI builders for Python, but don't rely on it to save you from learning something.
One of the best IDEs I've found (and I've used a lot of IDEs) is the OS, and tangent language tools themselves. For Perl, I use Vi, Gedit, or Textpad for my editor, GladeXML or perl scripts to generate UIs, bash/MakeMaker for my build system, and the other Unix tools to fill in the gaps. I've used some of the Perl IDEs in production environments, and they're all limited somewhere. Don't settle for one tool, as your tools contribute to the quality/quantity of what you produce. You can be in control.
Also missed out on textpattern. It's supposidly BSD-licensed, and fairly similar to MT.
Google almost does topic-searches, try: ~"TCP/IP tutorials" Which attempts to do a synonym-search, which is darned close to a topic search (in the way that I use it anyway).
I'm actually surprised that someone hasn't marketed this before. Last year while building an embedded system with Embedded XP, we built a few bootable XP CDs with various levels of the OS. A few years before that we did the same thing with 2000. And before that we had done it with NT too. We found that the CDs were a simple way to test our platform, without writing an eprom (or later to a DOC). We had no interest in marketing it as they were working in a vertical marketn (weren't interested in mass-marketing).
One thing that I've noticed, since I started using Gnu systems, is that it's like the good-old-days again -- just like the nostalgia of reading these old kid's programming books. Using the shell, and great languages like python and perl, has the same flavour, and freedoms that I enjoyed on my Atari 800 (and each subsequent box).
Maybe it's the availability of many, small, free programs -- which is a contrast to the windows pay-for-every-crappy-utility world. Maybe it's the large number of similar historied geeks that have created this free world, or maybe it's just my imagination. For big kids, anyway, the HOWTOs and other online gold are the next generation of our great past.
Uh, gtk is object based in case you haven't noticed. Just because it's written in C doesn't mean it can't use objects. Gtk+ allows for very decent subclassing, as does the plain-old-C Win32 GUI Apis for that matter, though I personally find the Gtk+ approach much cleaner (they've taken the time to develop a very clean API).
The only 'bloat' in Gtk+ may be in the infrastructure required to support C-style objects, but it does give one distinct advantage over using pure C++ (or Java) for the widget set: complete (and absolute) control. Notice what Trolltech has done with their QT widgets with the signal/slot pre-compilation process (they had to work around a limitation of the language), this is a decent approach but shows a minor limitation of the toolkit language. I think that QT is a great OO-style toolkit, as is Gtk+.
Try Typepad ... it's a pay-for service, but it's damned simple to use. I was a second-round beta tester, and I found it one of the easiest web-publishing software out there, as did the hundreds of other beta-testers I talked with. It's an updated version of MoveableType (which is also very good), but simplified for the average shmoe. It even includes a handy 'layout' editor, which allows the sort of page customization most people want, without *any* understanding of how the stuff actually works. Everything is simple, grokable, and does what it can to hide the technical details. It even has nifty features that auto-link amazon images to your posts and stuff. Safe for the whole family.
... and none of it was shmoe-worthy. It was all geek-worthy, but the many technical details dumbfounded the non-techs I know.
... but then again, I'm not normal people.
I've used most everything else over the last 10+ years: slashcode, phpnuke, pyblosxom, blosxom, moveabletype, citydesk, blogger
Note, I run my sites using blosxom, ssh, vi, and make
We've also heard, from within Samsung, that they will be producing Alphas for some time. But, at the same time, they seem to be migrating their internal IT use of Alpha to other platforms (lack of OS Vendor support).
My experience with Alpha development is only so-so. A great architecture, and a solid OS, but porting to it was almost as painful as HPuX -- for C++ at least. That really taught us a lesson, too, that C++ portability is still way back there. We found the same with Java too, at least on Alpha (the 1.4 JVM was in beta for more than year after it was released on windows).
Best is always arguable ;-) Both VIM and Emacs, though, are incredible code-editors, and are mature, feature-rich, and fun. VIM and Emacs are not toys, they are heavy-duty tools ... hence the not-so-lean-learning-curve.
There are *hundreds* of free text editors for GNU/Linux though, some of which are incredibly easy to use. Gedit, Scintilla, Glimmer, Anjuta, Pico, Nano, Jed are a few I can think of off the top of my head. The free Java editors work well too (Jedit, etc.).
I was thinking about this problem the other day, as it relates to open-source game development. One of the main problems with small-scale game development is the creation of content (it's a lot of effort), and algorithmic content would make it easier for a smaller-group of developers to build a good game.
But a problem with random content is that it can suck, like impossible nethack levels, etc., as the algorithms have no great sense of athstetics or any of the other abilities require to make 'good' levels. Designing algorithms to test for athstetics is also difficult, and probably only worth doing for a few cases.
The conclusing I came to was that algorithms could be used to pre-generate content (like maps, etc), in the sense of the "millions-of-monkeys" problem, except with a bit of focus. Algorithms would generate content (maps, shapes, etc.), and then the work would be filtered by the developers, and the good stuff made part of the game. The algorithms could also use some sort of learning to improve the generation process, similar to spam filtering - "this is spam" vs. "this is not spam" user-initiated filter improvement.
This sort of approach would really make small-shop game development easier, as would improving (and standardizing) content-production tools and processes.
You might try an Arm processor, many of which have great built-in features (like NIC, daq, memory management). You can get demo boards, and run linux + related gnu tools on them. ARM-based systems make great embedded/distributed systems (aka 'the future'), and are a useful to learn for the old-resume.
You think a process will make OSS better? The act of defining a process renders it useless, as the principles become static. Software will only get better when we do away with processes. Software is complex, it requires us to think -- not follow procedures.
I've been a part of many small and large processes, and none of them were effective. The best any of them were able to do was to soften what was produced by the morons. In lessening the effect of retarded developers, the processes become a hindering block to those who know wtf they are doing. Process is so fun.
Software development needs to be organic. OSS needs more mentors, gurus of the deep, dark, unknown to become one with the new blood. It is about community, and about collaboration - the real sort of kinship where people build things together. Process is about as un-personal as it gets.