gitfm is lacking sorely in a number of areas. Here're just a couple major ones:
- no vfs so you can't enter tar.gz files or rpms, or cpio files - keybinding support is inconsistent. For example often times F10 is mapped by the terminal or the windowing system to a particular function. Normally you'd expect that F10 and Esc-0 are the same. But this is not the case in gitfm. Although Esc-0 works from the main screen, you cannot use it to exit the "view" mode. - no apparent way to change directories in gitfm without drilling down.
For the few things I use mc for (checking out rpms, cpios, etc), gitfm just doesn't work.
Who says you can't configure Gnome? How is an obscure gconf key any worse than an obscure setting buried in some obscure dialog box? What does Gnome not do out of the box that you have to be able to configure it to do?
Smoke looks more like a COM-style marshalling system than a mere language binding. From what I've read, basically Smoke wraps every object in special qobject proxy. If this is correct, then my original reasoning stands. C++ requires wrappers or proxies to work well with other languages. gobject C-based libraries, as nasty as they are to develop, require much much less of this.
So no. Smoke bindings haven't proved me wrong.. in fact they've proved my original point. No the binding arguments aren't stupid. Besides all this, arguing that core Gnome APIs should be C++ based is just silly because they are already C-based. If we rewrote everything we'd just end up with KDE/Qt anyway.
Sure. But even swig would have a hard time with some C++ things going to, say python. In many cases it's not an automatic task. Hand coding (wrapping in straight C!) is still required in some circumstances. Currently GTK has managed to get it so that most bindings can be generated automatically with little wrapping required at all. This would not be possible with C++. Besides that fact, C++ libraries are a nightmare across compilers. With straight C, you can jump compiler and glibc revisions without many problems or recompiles. Bump the libstdc++ version and you're recompiling everything. No really. C++ is not a good language for base libraries.
How would XUL help build and extend Gnome applications? It just doesn't apply here. We're not talking about building rich web-based applications like XUL is for. We're talking scripting and extending Gnome binary applications that are already based on a nice API. Embedding gecko in every gnome app is silly. Having a way of embedding Javascript, or Lua, or Python in an app, and allow such scripting languages to access the core objects of the app and extend functionality is a very appropriate and very necessary. You wouldn't suggest that WoW programmers use XUL would you? Yet they have embedded Lua.
I think you're being led astray by the article building a complete little app as a demonstration. In reality this is not likely to be the case. Instead you'd have the bulk of the app written in, say, C, C++ or Python, and then have seed embedded to allow plugins and little custom, end-user scripts written in Javascript.
For an example of how this is going to work, take a look at what Epiphany is doing. Their core code is written in C I think, but you can write plugins in Python or C, and soon Javascript. By plugins I mean quick and dirty little things create smart bookmarks (just an example), or modify the behaviour of aspect of the UI. For example, I wrote a 10-line python script to clear the google search box every time you submit it. Thanks to exposing their objects through python, I could locate the widget in question, attach a handler to it to trap the "activate" signal, and then after letting the normal handlers do their work, I simply told the widget to clear its contents. Other things you can do include add menu items and toolbar items, remove elements of the UI (think kiosk mode), etc. Sure this is a browser and sure you can use XUL (and javascript only) to do that to firefox. That's not the point. The point is think about doing this to any gnome-based app. One other very important thing that will happen (and KDE has had it for years) will be the ability to, through the introspection API, dynamically drive an application through scripts, even though they are gui apps. Javascript would lend itself well to this.
Umm, because it's precisely the *right* language for the job. C++ restricts your binding options to other languages pretty dramatically, especially if you use parts of C++'s object model such as multiple inheritance. In short, no C++ is the wrong too for the job, Qt's use of it notwithstanding. Although it's true that Qt does have bindings for many languages, the simple fact is that these bindings, such as PyQT, are against the *C* wrapper on the C++ api. So an entire extra layer in the way. Gnome and GTK's gobject-based object model is just about one-to-one with most models of object-oriented languages. Hence you can use just about any language under the sun to develop Gnome apps. All without losing any features of the API.
If you do want to program in C with GTK, you can and it's very easy, actually. Memory leaks are minimized because of the coolness in glib. However, if you're not a C programmer then you shouldn't be programming GTK/Gnome apps in C at all. Use something more powerful like Python. In fact I can't think of any reason (except embedding on small systems, or core libraries and programs) where it's appropriate to write a Gnome app in C. There are tons of awesome bindings available. Use them. Write in C++ (which is a much nicer API at times than Qt's moc-ified native apis) if you want.
So yes. Gnome is able to target the languages that normal developers want to use. Whether that's C#/.Net, Python, C++, Ruby, or C.
If Gnome wasn't written in C, what language would you suggest? How would you provide extensive, 100% coverage of the API in any arbitrary language? Writing GTK itself in C# seems pretty silly. Same for Python, Ruby, etc, unless you want to restrict the entire toolkit to just one language.
Re:Vala makes the creating widgets argument moot
on
Qt Becomes LGPL
·
· Score: 2, Interesting
Vala is hardly a failure if you examine why it exists and what is used for (and how it relates to the post I was originally answering). Well Vala is really syntactic sugar over C and the existing gobject facilities. So yes, memory management isn't going to be like C#, and it's not like C++ either, alhough C++ doesn't have a garbage detector or a cycle detector... nothing big ever gets written in C++ for those reasons. Like Qt Apps. Right. Big applications can and have been written in straight C with GTK and have done fine. Worst case, Vala just makes writing such applications easier, though you do have to manage memory yourself.
But I should have been more clear when I was promoting Vala. Vala could be used to write big apps I'm sure, but like you say with real nice languages like Python, there's really no point. However I was addressing the concern expressed that creating new widgets in GTK or even extending widgets is very painful in C. Vala is intended to address this and make it easier to develop GTK libraries and extend GTK. That's the point.
Sure if you want to compare GTK to Qt you'd be better off to compare GTKmm to Qt. But of course if you were to write widgets in GTKmm you're locked to C++ and can never offer them to other languages without a port.
Re:Vala makes the creating widgets argument moot
on
Qt Becomes LGPL
·
· Score: 1
I guess I should have been more clear. I wasn't necessarily saying Vala was an app development language (although it could be). Actually the reason Vala exists is exactly to prevent creating a silo of code when it comes to developing and promoting GTK. If Gtk used some other language like, say, Python, with Python GTK widgets and so forth, then how would Java, C#, or even C or C++ have access to these components? They simply couldn't. Vala isn't actually a language in the same sense as Python, C# or Java is. It's really just a syntactic extension of C and produces plain, simple, C code.
Sorry but I'm very confused by some of your other comments. How will using Javascript help in GTK development or building custom widgets or extending GTK and its reach? Javascript is fine as a glue language, or even as a language to develop an extensible app in. Hence bindings to GTK are awesome for Javascript. But how does it address core GTK development issues? This is what Vala is really for. Sure apps could be and are written in Vala. But if core GTK development uses Vala extensively going forth, it will be possible to extend and improve GTK to equal Qt while still maintaining the ability to use it from any language binding.
So in short, Vala is going to prove the salvation of GTK itself for these reasons. I guess my original post wasn't clear enough. I never said Vala should be used to write applications necessarily. Just that it can be used to easily create new widgets or extend existing widgets. So if you're going to work with GTK development itself, or build libraries of GTK code (widgets, etc) that you can use anywhere, then Vala is the way to go.
Vala makes the creating widgets argument moot
on
Qt Becomes LGPL
·
· Score: 1, Insightful
Fortunately Vala makes this very easy to do. Defining a new widget is just a matter of creating a class and inheriting from some other widget and then adding in your code in a nice, C#-style syntax. And it compiles down to C code so the resulting gobject class can be used by normal C programs and libraries, and easily be wrapped in a language binding. I hope that in the near future most if not all GTK and Gnome programming, particularly when it comes to the GUI and defining widgets, will be done in Vala. Vala isn't really a new language per se. It's nice syntactic sugar that allows things to stay in C where they belong so they can be interfaced with and bound by programs in *any* language. Going forward, it's possible to develop GTK in Vala, all without ruining the purity of having a good C library that anyone can access.
Really Vala is proof that the GTK devs, when they defined the gobject model in pure C, where very forward-thinking. This isn't the kind of thing that could be easily done had GTK been based in C++. C++-based libraries are hell to work with, especially on Windows.
So very soon (within the year), I believe people will be comparing Vala-based GTK code with Qt in terms of ease of use, the API cleanliness, etc. Any arguments about the clumsiness of using C (and it is clumsy to define a new gobject class in C!) and GTK will be put to rest.
Re:Ubuntu annoyances?
on
Ubuntu Kung Fu
·
· Score: 2, Informative
On 8.4 and 8.10, it is as easy as windows. Just use nautilus to mount it and every application can see it through gvfs and also through a fuse mount in $HOME/.gvfs.
It's pretty slick. In addition to mounting windows shares, you can also mount via ssh. It's a bit like KDE's ioslaves, but a lot better integrated and can be used by all apps whether they are gvfs aware or not.
Sure but all OS's let you have the monitor turn off. I set my display to blank after 10 minutes and turn completely off after 15 minutes. Of course there's the issue of devices that are off not really being off and still drawing current...
There are versions of the book for Windows, Mac, and Linux. Although the book targets kids as young as 8, it would still be able to speak to an 11 or 12 year old I think.
I'm afraid you've dramatically missed the point. I'm not interested in selling my soul to Apple for this privilege. Initially I only made the purchase (and arguably it was foolish) because I knew I could jailbreak the device and do what I wanted with it. However, Apple chose to go to war against those who would use the device in ways Apple didn't want (oh the irony of living in a free country) and they have decided it's illegal for me to use my iPod to sync against Amarok if I ever upgrade to 2.x (which they practically force on me every time I plug it into a computer with iTunes on it).
I want a platform that I'm free to do anything I want with, since I own it. I want to be able to write new software, access the shell, sync against amarok, etc. I don't want to pay apple $100 for the privilege of accessing a device I already own and should have access too. That's just silly and a bit ludicrous if you think about it. Cue the bad car analogies... Sure we'll sell you a car. But if you want access to the trunk you have to pay us for a trunk license and then we reserve the right to take away the key at any time if we see fit.
As for being compensated for my work, Apple's policies don't even allow GPL'd software at all, so I couldn't even offer my work to others to begin with.
In hindsight, the iPod was a stupid buy. It doesn't work well with just about anything. I can't easily attach peripherals to it, except what Apple sanctions. However at the time it was the best device (when jailbroken) on the planet. I'm hoping that a device with Android will reach that point soon.
I don't really need or want an iPhone or an Android phone. What I want is a nice, compact, multi-touch platform like the iPod Touch that runs android. Android has the potential to power a real iPod killer that's a nice platform for all kinds of apps.
Initially I was very excited about the iPod Touch and bought one. But Apple's desire to completely and utterly control what I do with my own device has really turned me off of it. If I could have a similar device that was open to installation of apps and development without deferring to the whims of Google or any other manufacturer, I'd gladly shell out another $300 for an android device sans phone. Seems like manufactures aren't even bothering to compete with Apple in general (maybe android isn't good enough to compete with the iPhone and iPod touch), but rather are aiming for the already existing market of mediocre products such as blackberry, palm, and windows smartphones. Kind of sad, really. In this market things like video and audio playback seem almost like afterthoughts, which poorly designed apps to do this and little to no support for integrating with PC-based software, such as would be similar to iTunes. Sure you can dump songs on a little chip, but how well does the playback system work? is it fully integrated like it is on the iPhone and obviously the iPod Touch? How well can it integrate with Amarok or Songbird? Seems like there are a lot of opportunities here. Of course maybe they feel the mp3 player market is so saturated that it doesn't matter. After all business users care mainly about their e-mail. I get the impression I will never be in the target market for any of these companies.
I switched to only allowing keys a long time ago. This stops this attack dead, whether it is distributed or not. If I ever lock myself out, or use a computer where I don't have any keys already set up, I have a special, password-encrypted key that I can access over an authenticated https url.
On my VPS I took advantage of SSH's new configuration features to disable password authentication for outside connections, but allow password for connections coming from within my wide-area private network (openvpn rocks!). But with the stored, accessible, ssh key on the server itself, I rarely need to use a password directly, ever.
Yeah, of course it's not *free*. But you have your units all crossed. The amount of energy used to create the plasma turbines would be some fixed unit of energy, like joules. The total energy consumed by all the milling machines, trucks to haul the parts, build the plant, etc. But that's a fixed, sunk cost.
The electricity generated by this process (which *is* self-sustaining once it gets started), is measured in watts, which is work done over time! So generating 60 MW means that it's 60,000,000 Joules per second if I remember my physics. So over years, for example, the energy produced (recovered from otherwise wasted energy in the form of garbage) probably pays for the energy cost of building by a huge factor.
Umm, no, that's not what a firewall is for. A firewall does nothing to prevent exploits against services you need to be offering to the world, like a web server. A firewall is only intended to control who accesses what, if a service needs to be selectively offered. I don't run firewalls on any of my servers and I sure as hell don't trust hosts on my network. But a firewall in this situation is stupid. ACLs on the router already control ssh access (from my admin vlan only). What good is a firewall that blocks ports that are already closed?
No, the advice in the parent post is very good and very clear.
Unlike how MS competes in the desktop space, where the intel/windows hegemony pretty much precludes all direct competition, this cloud hosting thing is a different beast altogether. In the world of this kind of app development, it's really just a matter of APIs. The platform doesn't matter so much because the high-level APIs are the platform. And Windows Azure is sufficiently different from standard win32 apps and programming that current win32 developers really have no inherent advantage. The jump to Azure is no different than the jump to, say, django on Amazon's cloud service. Or IBM's or whatever. So when it comes to cloud computing, MS has to compete like any new service. This is a good thing. Of course they are trying to apply their standard business techniques to it (lock-in, etc), but that's likely to fail as the other alternatives are just as capable without the lock-in. It will be fascinating to see how MS does when it is forced to actually compete with strong competitors and capable and entrenched existing systems. Unless they can find a way to strongly tie into their win32 platform (say some kind of MS Office/Sharepoint integration that is the cat's pajamas, or some kind of integration with IE for the client side), I don't think they can honestly remember how to compete here. Should be interesting, especially as PHBs have wisened up a bit over the years.
I realize that video recorders and many other devices are still predominantly firewire. But for most external drives and even still cameras, USB reigns supreme and is about as fast. Probably Apple's view is that if you're into video editing, you ought to be paying the big bucks for the privilege of using firewire on a top-of-the-line machine.
Does not Apple support target-mode with USB these days? It seems like it should be possible for Apple to make the device appear as a USB mass storage device.
I bought a little computer called a ScanGuage (check with Dr Google for web sites) that measures fuel consumption and a whole host of other variables. I found my car gets absolutely worst mileage between 0 and 30 mph. The best mileage I get is around 55, which is kind of what a lot of average cars do. There's a balance you have to strike in city driving.
Punching it off the light drops my mileage down to 3-4 MPG for the duration of the burst. If I accelerate a little less quickly, I can get no lower than 10 MPG. The catch is mileage is horrible under 25 anyway, so the quicker you can get your car past that speed the better, but punching it in time to brake for the next light is probably pretty silly too.
Overall the best way to get better mileage is to adjust your speed to minimize the times you have to accelerate and decelerate. IE if you know a red light up ahead is going to change soon, slow down a bit so that by the time you get to the light it will be green. This can save a lot of fuel because you have to spend less energy accelerating.
Also, I've found that the smoother you're driving, the better mileage you get. While accelerating, shift smoothly, rather than the bursts of acceleration that most folks do. In fact, a passenger can't even tell you shifted (or the car shifted), mileage improves.
Also when on cruise control, be more proactive around hills. Disengage the cruise early and accelerate some so that your momentum can better carry you over the hill. Don't wait for the car to down-shift. Let the car slow down some so that down-shifting isn't necessary. On the other side of the hill, gently accelerate to the speed you want to cruise at before turning cruise back on as cruise tends to cause things like down-shifting when accelerating. One other tip when climbing a small hill on cruise control (with an automatic with a locking torque-converter) is to tap the accelerator, which unlocks the torque converter. This will give you a bit more power without resorting to a downshift (you should see your tach rise slightly).
Anyway there are lots of things people can do to drive better and save fuel. Also passengers tend to be more comfortable too, with less motion sickness.
Buffet has enough cash to weather the storm with or without the rescue plan. In fact, in an attempt to bolster confidence in lending institutions recently announced a multi-billion dollar investment in one of the troubled firms.
Your comment about dishonest people losing their money is the crux of the whole issue. Sadly the majority of folks who now bear the financial results of the actions of dishonest investors are the honest folks. That's why the rescue plan is essential. Sadly it does benefit the dishonest as well as the honest. We can and should enact laws (regulation!) to prevent gaming of the system. Of course we used to have those laws and regulations, but both republican and democratic presidencies in years past removed them, saying that the market would regulate itself.
Just because large masses of stupid people urge something doesn't mean it's necessarily a good thing. And polls indicate that the American people were equally split on the issue, not overwhelmingly opposed to it, as you intimate. It is a fallacy to suggest that 90,000 phone calls is representative of her constituency. Most folks in favor of the rescue plan probably never said anything because the situation logically demanded the rescue; they knew Feinstein would vote for it.
I take it you'd have been in favor of letting American tax payers lose 700 billion in assets straight away rather than spending the money to rescue the economy and making back the same 700 billion (just barely if we're lucky) over the next few years. Letting the tax payers just suck it all up big losses would have been very unfair, and incredibly damaging in the long term. I'd be in favor of just letting all the companies collapse--if the people who ended up with all the losses where the folks who opposed the rescue plan. That would serve them right. But that isn't what would happen. Instead, many honest, hard-working Americans who were paying back their loans would lose the most because they were being dragged down by all the bad loans. Better to nationalize some lending institutions. We know from other economies that such a move does in fact work.
I'd have opposed the rescue plan too, except that Warren Buffet, who's one of the smartest financial men in America, and one of the most conservative, said it was not only a good idea, but essential. I give his opinion more weight than 90,000 folks who barely comprehend the system. Of course it's a shame that the rescue plan was not able to really clamp down on the companies and CEOs and restore regulation and stop this ridiculous habit we have of lending money we don't have at the ratios we have been allowing (4:1, if you can believe that). Congress will do that in the coming years, hopefully.
Slashdot Mirror
gitfm is lacking sorely in a number of areas. Here're just a couple major ones:
- no vfs so you can't enter tar.gz files or rpms, or cpio files
- keybinding support is inconsistent. For example often times F10 is mapped by the terminal or the windowing system to a particular function. Normally you'd expect that F10 and Esc-0 are the same. But this is not the case in gitfm. Although Esc-0 works from the main screen, you cannot use it to exit the "view" mode.
- no apparent way to change directories in gitfm without drilling down.
For the few things I use mc for (checking out rpms, cpios, etc), gitfm just doesn't work.
Who says you can't configure Gnome? How is an obscure gconf key any worse than an obscure setting buried in some obscure dialog box? What does Gnome not do out of the box that you have to be able to configure it to do?
For others' information: http://techbase.kde.org/Development/Languages/Smoke
Smoke looks more like a COM-style marshalling system than a mere language binding. From what I've read, basically Smoke wraps every object in special qobject proxy. If this is correct, then my original reasoning stands. C++ requires wrappers or proxies to work well with other languages. gobject C-based libraries, as nasty as they are to develop, require much much less of this.
So no. Smoke bindings haven't proved me wrong.. in fact they've proved my original point. No the binding arguments aren't stupid. Besides all this, arguing that core Gnome APIs should be C++ based is just silly because they are already C-based. If we rewrote everything we'd just end up with KDE/Qt anyway.
Sure. But even swig would have a hard time with some C++ things going to, say python. In many cases it's not an automatic task. Hand coding (wrapping in straight C!) is still required in some circumstances. Currently GTK has managed to get it so that most bindings can be generated automatically with little wrapping required at all. This would not be possible with C++. Besides that fact, C++ libraries are a nightmare across compilers. With straight C, you can jump compiler and glibc revisions without many problems or recompiles. Bump the libstdc++ version and you're recompiling everything. No really. C++ is not a good language for base libraries.
How would XUL help build and extend Gnome applications? It just doesn't apply here. We're not talking about building rich web-based applications like XUL is for. We're talking scripting and extending Gnome binary applications that are already based on a nice API. Embedding gecko in every gnome app is silly. Having a way of embedding Javascript, or Lua, or Python in an app, and allow such scripting languages to access the core objects of the app and extend functionality is a very appropriate and very necessary. You wouldn't suggest that WoW programmers use XUL would you? Yet they have embedded Lua.
I think you're being led astray by the article building a complete little app as a demonstration. In reality this is not likely to be the case. Instead you'd have the bulk of the app written in, say, C, C++ or Python, and then have seed embedded to allow plugins and little custom, end-user scripts written in Javascript.
For an example of how this is going to work, take a look at what Epiphany is doing. Their core code is written in C I think, but you can write plugins in Python or C, and soon Javascript. By plugins I mean quick and dirty little things create smart bookmarks (just an example), or modify the behaviour of aspect of the UI. For example, I wrote a 10-line python script to clear the google search box every time you submit it. Thanks to exposing their objects through python, I could locate the widget in question, attach a handler to it to trap the "activate" signal, and then after letting the normal handlers do their work, I simply told the widget to clear its contents. Other things you can do include add menu items and toolbar items, remove elements of the UI (think kiosk mode), etc. Sure this is a browser and sure you can use XUL (and javascript only) to do that to firefox. That's not the point. The point is think about doing this to any gnome-based app. One other very important thing that will happen (and KDE has had it for years) will be the ability to, through the introspection API, dynamically drive an application through scripts, even though they are gui apps. Javascript would lend itself well to this.
Umm, because it's precisely the *right* language for the job. C++ restricts your binding options to other languages pretty dramatically, especially if you use parts of C++'s object model such as multiple inheritance. In short, no C++ is the wrong too for the job, Qt's use of it notwithstanding. Although it's true that Qt does have bindings for many languages, the simple fact is that these bindings, such as PyQT, are against the *C* wrapper on the C++ api. So an entire extra layer in the way. Gnome and GTK's gobject-based object model is just about one-to-one with most models of object-oriented languages. Hence you can use just about any language under the sun to develop Gnome apps. All without losing any features of the API.
If you do want to program in C with GTK, you can and it's very easy, actually. Memory leaks are minimized because of the coolness in glib. However, if you're not a C programmer then you shouldn't be programming GTK/Gnome apps in C at all. Use something more powerful like Python. In fact I can't think of any reason (except embedding on small systems, or core libraries and programs) where it's appropriate to write a Gnome app in C. There are tons of awesome bindings available. Use them. Write in C++ (which is a much nicer API at times than Qt's moc-ified native apis) if you want.
So yes. Gnome is able to target the languages that normal developers want to use. Whether that's C#/.Net, Python, C++, Ruby, or C.
If Gnome wasn't written in C, what language would you suggest? How would you provide extensive, 100% coverage of the API in any arbitrary language? Writing GTK itself in C# seems pretty silly. Same for Python, Ruby, etc, unless you want to restrict the entire toolkit to just one language.
Vala is hardly a failure if you examine why it exists and what is used for (and how it relates to the post I was originally answering). Well Vala is really syntactic sugar over C and the existing gobject facilities. So yes, memory management isn't going to be like C#, and it's not like C++ either, alhough C++ doesn't have a garbage detector or a cycle detector... nothing big ever gets written in C++ for those reasons. Like Qt Apps. Right. Big applications can and have been written in straight C with GTK and have done fine. Worst case, Vala just makes writing such applications easier, though you do have to manage memory yourself.
But I should have been more clear when I was promoting Vala. Vala could be used to write big apps I'm sure, but like you say with real nice languages like Python, there's really no point. However I was addressing the concern expressed that creating new widgets in GTK or even extending widgets is very painful in C. Vala is intended to address this and make it easier to develop GTK libraries and extend GTK. That's the point.
Sure if you want to compare GTK to Qt you'd be better off to compare GTKmm to Qt. But of course if you were to write widgets in GTKmm you're locked to C++ and can never offer them to other languages without a port.
I guess I should have been more clear. I wasn't necessarily saying Vala was an app development language (although it could be). Actually the reason Vala exists is exactly to prevent creating a silo of code when it comes to developing and promoting GTK. If Gtk used some other language like, say, Python, with Python GTK widgets and so forth, then how would Java, C#, or even C or C++ have access to these components? They simply couldn't. Vala isn't actually a language in the same sense as Python, C# or Java is. It's really just a syntactic extension of C and produces plain, simple, C code.
Sorry but I'm very confused by some of your other comments. How will using Javascript help in GTK development or building custom widgets or extending GTK and its reach? Javascript is fine as a glue language, or even as a language to develop an extensible app in. Hence bindings to GTK are awesome for Javascript. But how does it address core GTK development issues? This is what Vala is really for. Sure apps could be and are written in Vala. But if core GTK development uses Vala extensively going forth, it will be possible to extend and improve GTK to equal Qt while still maintaining the ability to use it from any language binding.
So in short, Vala is going to prove the salvation of GTK itself for these reasons. I guess my original post wasn't clear enough. I never said Vala should be used to write applications necessarily. Just that it can be used to easily create new widgets or extend existing widgets. So if you're going to work with GTK development itself, or build libraries of GTK code (widgets, etc) that you can use anywhere, then Vala is the way to go.
Fortunately Vala makes this very easy to do. Defining a new widget is just a matter of creating a class and inheriting from some other widget and then adding in your code in a nice, C#-style syntax. And it compiles down to C code so the resulting gobject class can be used by normal C programs and libraries, and easily be wrapped in a language binding. I hope that in the near future most if not all GTK and Gnome programming, particularly when it comes to the GUI and defining widgets, will be done in Vala. Vala isn't really a new language per se. It's nice syntactic sugar that allows things to stay in C where they belong so they can be interfaced with and bound by programs in *any* language. Going forward, it's possible to develop GTK in Vala, all without ruining the purity of having a good C library that anyone can access.
Really Vala is proof that the GTK devs, when they defined the gobject model in pure C, where very forward-thinking. This isn't the kind of thing that could be easily done had GTK been based in C++. C++-based libraries are hell to work with, especially on Windows.
So very soon (within the year), I believe people will be comparing Vala-based GTK code with Qt in terms of ease of use, the API cleanliness, etc. Any arguments about the clumsiness of using C (and it is clumsy to define a new gobject class in C!) and GTK will be put to rest.
On 8.4 and 8.10, it is as easy as windows. Just use nautilus to mount it and every application can see it through gvfs and also through a fuse mount in $HOME/.gvfs.
It's pretty slick. In addition to mounting windows shares, you can also mount via ssh. It's a bit like KDE's ioslaves, but a lot better integrated and can be used by all apps whether they are gvfs aware or not.
Well go right ahead. It's called X-Plane and it's available on Linux even. The UI is quirky, but the flight model is second to none. Only $50 I think.
Sure but all OS's let you have the monitor turn off. I set my display to blank after 10 minutes and turn completely off after 15 minutes. Of course there's the issue of devices that are off not really being off and still drawing current...
Forgot to mention, this book is about Python! Just so the moderators know! :)
I know several young people who've got hooked on programming because of this free book: http://www.briggs.net.nz/log/writing/snake-wrangling-for-kids/
There are versions of the book for Windows, Mac, and Linux. Although the book targets kids as young as 8, it would still be able to speak to an 11 or 12 year old I think.
I'm afraid you've dramatically missed the point. I'm not interested in selling my soul to Apple for this privilege. Initially I only made the purchase (and arguably it was foolish) because I knew I could jailbreak the device and do what I wanted with it. However, Apple chose to go to war against those who would use the device in ways Apple didn't want (oh the irony of living in a free country) and they have decided it's illegal for me to use my iPod to sync against Amarok if I ever upgrade to 2.x (which they practically force on me every time I plug it into a computer with iTunes on it).
I want a platform that I'm free to do anything I want with, since I own it. I want to be able to write new software, access the shell, sync against amarok, etc. I don't want to pay apple $100 for the privilege of accessing a device I already own and should have access too. That's just silly and a bit ludicrous if you think about it. Cue the bad car analogies... Sure we'll sell you a car. But if you want access to the trunk you have to pay us for a trunk license and then we reserve the right to take away the key at any time if we see fit.
As for being compensated for my work, Apple's policies don't even allow GPL'd software at all, so I couldn't even offer my work to others to begin with.
In hindsight, the iPod was a stupid buy. It doesn't work well with just about anything. I can't easily attach peripherals to it, except what Apple sanctions. However at the time it was the best device (when jailbroken) on the planet. I'm hoping that a device with Android will reach that point soon.
I don't really need or want an iPhone or an Android phone. What I want is a nice, compact, multi-touch platform like the iPod Touch that runs android. Android has the potential to power a real iPod killer that's a nice platform for all kinds of apps.
Initially I was very excited about the iPod Touch and bought one. But Apple's desire to completely and utterly control what I do with my own device has really turned me off of it. If I could have a similar device that was open to installation of apps and development without deferring to the whims of Google or any other manufacturer, I'd gladly shell out another $300 for an android device sans phone. Seems like manufactures aren't even bothering to compete with Apple in general (maybe android isn't good enough to compete with the iPhone and iPod touch), but rather are aiming for the already existing market of mediocre products such as blackberry, palm, and windows smartphones. Kind of sad, really. In this market things like video and audio playback seem almost like afterthoughts, which poorly designed apps to do this and little to no support for integrating with PC-based software, such as would be similar to iTunes. Sure you can dump songs on a little chip, but how well does the playback system work? is it fully integrated like it is on the iPhone and obviously the iPod Touch? How well can it integrate with Amarok or Songbird? Seems like there are a lot of opportunities here. Of course maybe they feel the mp3 player market is so saturated that it doesn't matter. After all business users care mainly about their e-mail. I get the impression I will never be in the target market for any of these companies.
I switched to only allowing keys a long time ago. This stops this attack dead, whether it is distributed or not. If I ever lock myself out, or use a computer where I don't have any keys already set up, I have a special, password-encrypted key that I can access over an authenticated https url.
On my VPS I took advantage of SSH's new configuration features to disable password authentication for outside connections, but allow password for connections coming from within my wide-area private network (openvpn rocks!). But with the stored, accessible, ssh key on the server itself, I rarely need to use a password directly, ever.
Yeah, of course it's not *free*. But you have your units all crossed. The amount of energy used to create the plasma turbines would be some fixed unit of energy, like joules. The total energy consumed by all the milling machines, trucks to haul the parts, build the plant, etc. But that's a fixed, sunk cost.
The electricity generated by this process (which *is* self-sustaining once it gets started), is measured in watts, which is work done over time! So generating 60 MW means that it's 60,000,000 Joules per second if I remember my physics. So over years, for example, the energy produced (recovered from otherwise wasted energy in the form of garbage) probably pays for the energy cost of building by a huge factor.
Umm, no, that's not what a firewall is for. A firewall does nothing to prevent exploits against services you need to be offering to the world, like a web server. A firewall is only intended to control who accesses what, if a service needs to be selectively offered. I don't run firewalls on any of my servers and I sure as hell don't trust hosts on my network. But a firewall in this situation is stupid. ACLs on the router already control ssh access (from my admin vlan only). What good is a firewall that blocks ports that are already closed?
No, the advice in the parent post is very good and very clear.
Unlike how MS competes in the desktop space, where the intel/windows hegemony pretty much precludes all direct competition, this cloud hosting thing is a different beast altogether. In the world of this kind of app development, it's really just a matter of APIs. The platform doesn't matter so much because the high-level APIs are the platform. And Windows Azure is sufficiently different from standard win32 apps and programming that current win32 developers really have no inherent advantage. The jump to Azure is no different than the jump to, say, django on Amazon's cloud service. Or IBM's or whatever. So when it comes to cloud computing, MS has to compete like any new service. This is a good thing. Of course they are trying to apply their standard business techniques to it (lock-in, etc), but that's likely to fail as the other alternatives are just as capable without the lock-in. It will be fascinating to see how MS does when it is forced to actually compete with strong competitors and capable and entrenched existing systems. Unless they can find a way to strongly tie into their win32 platform (say some kind of MS Office/Sharepoint integration that is the cat's pajamas, or some kind of integration with IE for the client side), I don't think they can honestly remember how to compete here. Should be interesting, especially as PHBs have wisened up a bit over the years.
I realize that video recorders and many other devices are still predominantly firewire. But for most external drives and even still cameras, USB reigns supreme and is about as fast. Probably Apple's view is that if you're into video editing, you ought to be paying the big bucks for the privilege of using firewire on a top-of-the-line machine.
Does not Apple support target-mode with USB these days? It seems like it should be possible for Apple to make the device appear as a USB mass storage device.
The original series had rankings on the cuffs of the sleeves. http://en.wikipedia.org/wiki/Starfleet_ranks_and_insignia
I bought a little computer called a ScanGuage (check with Dr Google for web sites) that measures fuel consumption and a whole host of other variables. I found my car gets absolutely worst mileage between 0 and 30 mph. The best mileage I get is around 55, which is kind of what a lot of average cars do. There's a balance you have to strike in city driving.
Punching it off the light drops my mileage down to 3-4 MPG for the duration of the burst. If I accelerate a little less quickly, I can get no lower than 10 MPG. The catch is mileage is horrible under 25 anyway, so the quicker you can get your car past that speed the better, but punching it in time to brake for the next light is probably pretty silly too.
Overall the best way to get better mileage is to adjust your speed to minimize the times you have to accelerate and decelerate. IE if you know a red light up ahead is going to change soon, slow down a bit so that by the time you get to the light it will be green. This can save a lot of fuel because you have to spend less energy accelerating.
Also, I've found that the smoother you're driving, the better mileage you get. While accelerating, shift smoothly, rather than the bursts of acceleration that most folks do. In fact, a passenger can't even tell you shifted (or the car shifted), mileage improves.
Also when on cruise control, be more proactive around hills. Disengage the cruise early and accelerate some so that your momentum can better carry you over the hill. Don't wait for the car to down-shift. Let the car slow down some so that down-shifting isn't necessary. On the other side of the hill, gently accelerate to the speed you want to cruise at before turning cruise back on as cruise tends to cause things like down-shifting when accelerating. One other tip when climbing a small hill on cruise control (with an automatic with a locking torque-converter) is to tap the accelerator, which unlocks the torque converter. This will give you a bit more power without resorting to a downshift (you should see your tach rise slightly).
Anyway there are lots of things people can do to drive better and save fuel. Also passengers tend to be more comfortable too, with less motion sickness.
Buffet has enough cash to weather the storm with or without the rescue plan. In fact, in an attempt to bolster confidence in lending institutions recently announced a multi-billion dollar investment in one of the troubled firms.
Your comment about dishonest people losing their money is the crux of the whole issue. Sadly the majority of folks who now bear the financial results of the actions of dishonest investors are the honest folks. That's why the rescue plan is essential. Sadly it does benefit the dishonest as well as the honest. We can and should enact laws (regulation!) to prevent gaming of the system. Of course we used to have those laws and regulations, but both republican and democratic presidencies in years past removed them, saying that the market would regulate itself.
Just because large masses of stupid people urge something doesn't mean it's necessarily a good thing. And polls indicate that the American people were equally split on the issue, not overwhelmingly opposed to it, as you intimate. It is a fallacy to suggest that 90,000 phone calls is representative of her constituency. Most folks in favor of the rescue plan probably never said anything because the situation logically demanded the rescue; they knew Feinstein would vote for it.
I take it you'd have been in favor of letting American tax payers lose 700 billion in assets straight away rather than spending the money to rescue the economy and making back the same 700 billion (just barely if we're lucky) over the next few years. Letting the tax payers just suck it all up big losses would have been very unfair, and incredibly damaging in the long term. I'd be in favor of just letting all the companies collapse--if the people who ended up with all the losses where the folks who opposed the rescue plan. That would serve them right. But that isn't what would happen. Instead, many honest, hard-working Americans who were paying back their loans would lose the most because they were being dragged down by all the bad loans. Better to nationalize some lending institutions. We know from other economies that such a move does in fact work.
I'd have opposed the rescue plan too, except that Warren Buffet, who's one of the smartest financial men in America, and one of the most conservative, said it was not only a good idea, but essential. I give his opinion more weight than 90,000 folks who barely comprehend the system. Of course it's a shame that the rescue plan was not able to really clamp down on the companies and CEOs and restore regulation and stop this ridiculous habit we have of lending money we don't have at the ratios we have been allowing (4:1, if you can believe that). Congress will do that in the coming years, hopefully.