Gee, that must be it. If you claim X is not sufficiently responsive, has an inconsistent user interface, or is poorly architected, you must never have written software, or nobody has ever used your software. I'm glad you found me out.
This kind of attitude is repugnant, and I'm not clear why it's so prevalent on Slashdot. I love XFree86, it was a great product for it's day, and for a period of time I have used Enlightenment, Gnome and KDE as my desktop environments, all running on top of good ol' XFree. However, in the last several years, recent versions of Windows running on modern hardware are simply far more responsive subjectively (and yes, subjective responsiveness is the most important issue from a user interface and human factors perspective, not raw primitive throughput, where we all know X is great) and have better UI consistency at the widget level (is it great? no, if you want great consistency, you have to use Mac).
Definitely, which is why you shouldn't leave a static image on it at all. Something more visually interesting is more appropriate for the medium anyway.
Okay, I'm know, I'm slash-pimping my own work here, but it's directly relevant. You could also get a very, very cool interactive art installation from Irreverie Studios and run it on a large-screen LCD when you're not using it as your TV - it makes an awesome living room background piece for parties and social events.
Yes, we do get a substantial number of people interested in doing this, and running our beautiful 3D screensavers on a 40-something inch LCD or plasma display looks absolutely amazing. We did a display at SIGGRAPH and at a party here in New York recently, and people can't help staring. If you already have the display, we can set it up for you on a stock small-form-factor PC (our installation work is all custom to-order, so drop us a line), or feel free to roll your own with our 20 dollar screen toy/screensaver.
No, it doesn't use the network layer. Yes, it does use domain sockets. Yes, the X protocol is a high-chatter, high-latency protocol, despite the fact that you can get a high throughput of X requests if you don't look at the reality of round-trip latency the way most toolkits are used.
Face it, X is not goddamned Speedy Gonzalez, and everybody suggesting that it is needs to try it for themselves running decent, modern apps on a real desktop environment and stop whining "it's not X's fault, it's GNOME/KDE/Gtk/Qt/whatever else that uses X - if you just used ugly old Xlib apps and handrolled your own Xlib code, it would be uber-fast". Y Windows definitely has the right idea - combine the toolkit and the windowing system to provide decent UI consistency and potential for substantially better performance, and improved overall maintainability and distribution of applications, which are now written to a higher level API, not bundled with lots of toolkit library dependencies out the wazoo.
Well, because that's incredibly inefficient, doesn't lend itself to standardization of applications, doesn't lend itself to networked usage, makes it hard to change or update anything at a system-wide level to reflect changes in technology over time (instead, every application has to be rebuilt and recompiled using the latest, greatest, libraries). You're right, it's the way XFree86 is going, but it's definitely not the right way (I realize you were probably being sarcastic, but I've seen a lot of that attitude expressed sincerely on Slashdot, blindly defending the X model and XFree86).
Incidental success...
on
Bitter EJB
·
· Score: 5, Interesting
If EJB can be used to put together a scalable, efficient, powerful system, it's surely only incidental. My problem with the EJB model in general is that there seem to be far, far more ways to build systems that don't scale, make inefficient use of resources, and generally suck than there are ways to make a system that scales, works and doesn't suck. Sure, you can say that of any programming language, I know that. But I'm looking at other "whole system" APIs that I can think of.
For example, most GUI toolkits. Usually, you follow the examples and tutorials as a model, you read through the API docs, and you can build a system that works pretty well. Even many other kinds of enterprise software infrastructure - take TIB Rendezvous, or similar messaging systems - I've written apps with many of them that scale, are efficient and work well on the first try.
I've seen several EJB apps written, and worked on a few myself, and you can read all the damned API docs, follow Sun's examples, read your app server documentation, and so on, and still, you just shoot yourself in the foot. This isn't the first book on patterns and anti-patterns of EJB usage, it's the umpteenth. Why? Because the EJB model was so poorly thought out prior to its implementation that if you follow the specs and build the kind of system they _seem_ to want you to build, it just doesn't work.
Instead you need to have built 10 systems that don't work before you have a clue how to make one that doesn't. Frankly, it seems to me like more trouble than it's worth for what you get (which is basically transaction-aware objects, at least based on my knowledge from the EJB 1.1 era). If you just use session beans, if you don't use entity beans, if you don't do distributed transactions, if you don't use stateful session beans... then you can build an app that works.
Great. I think the J2EE APIs have a lot of great, great stuff in them, but EJB just tweaks me out. Why the hell didn't somebody try using this hunk-a-junk before they released their 1.0 spec, or maybe their 1.1 spec, or howzabout the 2.0 spec? Maybe things are better these days, but if your API looks like it's supposed to provide a pattern for enterprise database applications, shouldn't it actually do that, or somehow redefine what the hell it's really supposed to be for?
In the US, these kinds of cars are called "FFVs" or Flexible Fuel Vehicles. They are nearly identical to a normal gasoline engine in terms of efficiency burning gas, and I assume roughly comparable to an ethanol-only engine when burning ethanol. The versions here in the US switch combustion modes, fuel-air mixture ratios (and maybe compression ratios? probably not yet, but they should) depending on the ethanol/gasoline mix ratio they detect in the tank. It's basically a normal gas engine, with some smart electronics controlling it, and materials designed to store and burn across a range of mixtures and temperatures.
We have well over a million FFVs on the road in the US already, but very few people even realize that they have them, because few manufacturers actually market the fact that their cars have FFV engines. They simply make them with FFVs for the tax breaks they get making reduced emission or alternative fuel vehicles. Unfortunately, the result is that very few people outside of certain areas (like parts of the midwest where corn ethanol is produced in bulk) know about this, or ever use ethanol in their cars.
Ethanol isn't quite as dense an energy storage medium as gasoline, but the numbers I recall are that ethanol combustion yields about 33% less energy per unit volume than gasoline (though your numbers are a bit less favorable than that). However, strangely, in practice, E85 (85% ethanol, 15% gasoline - as you point out, using some gasoline affords other benefits in terms of viscosity, operating temperature range, and engine lubrication) powered FFV vehicles seem to get only about 15-20% fewer miles per gallon in normal operation than when burning gasoline. So yes, you have to use roughly 20-25% more fuel, but that's hardly a deal breaker, and is well within normal variations within existing vehicle classes. As long as the ethanol fuel pricing reflects this fact (i.e. 20% cheaper per gallon than gasoline, so your cost per mile travelled is comparable), I don't think the average consumer would really care.
The nice thing about ethanol is that it's quite efficient and inexpensive to make, relative to the biodiesels and other lipid-derived heavy fuels that can also be made from biological sources. The amount of government subsidy and capital investment required to transition to ethanol is tiny compared to switching to hydrogen, or to making biodiesel or similar fuels cost effective (see the current numbers on biodiesel from DOE and NREL - it is still a factor of 2-3 away from cost competiveness, whereas bioethanol is perhaps 20%-30% away from cost-competitiveness).
I don't think I spouted anything sensationalist. I thought we all knew how to use Google here.
I'll start you off with this overview link. Then I'll direct you here to read an energy security justification of the Biofuels research program at the DOE. If you are interested in reading a technical and economic assessment of one such program in this area, I encourage you to read this report from the NREL (big PDF warning) which has lots and lots of numbers to backup a feasibility analysis of large scale bioethanol production. Search around the ott.doe.gov/biofuels page, you'll find tons and tons more research and useful information, and hopefully you won't think this is just "snake oil".
Yes, yes, I understand that you can make a perfectly fine laissez faire argument against government intervention on a purely economic basis. I was not arguing that the government _should_ intervene based on economics, I have merely suggested that the government _should_ intervene in the free market for political reasons. If our government is willing to spend hundreds of billions to protect our oil supply, you can't argue that they currently let the market take care of itself. I am merely suggesting that an alternate investment of a small portion of the money spent protecting our current oil supply, say a few billion dollars a year, would go a long way toward cultivating a viable ethanol infrastructure here in the US, which would encourage people to purchase existing, already available FFVs. Once a critical mass of FFV ownership were achived, and a critical mass of ethanol fueling stations and production infrastructure existed, I don't see any reason that the government should or would continue to subsidize it's production, and think of all the taxpayer dollars saved by not having to deploy our military every time the oil supply is threatened.
My point in my first post was simply that alternatives exist. I don't really give a shit about how many tons of this or that are used if it makes sense economically, politically and environmentally (or rather, I think environmental impact should be factored into overall lifecycle cost analysis). In terms of arguing that oil is cheaper, it's only cheaper when you ignore the sociopolitical impact and costs that are hidden at the pump because they are incurred at the federal government level, in the way your taxpayer dollars and the wealth of the First World is allocated to defense spending.
That's right, there are great solutions out there that are far more efficient. But the unfortunate reality right now is that the economics of pumping shit out of the ground is very, very hard to compete with. The cost basis of oil (formed mostly by transportation, corruption and cronyism) vs. any harvested biological feedstocks used to make ethanol or biodiesel may be closer to competitive these days, but it's unlikely that the harvested feedstocks will ever win out by a large enough margin to encourage the capital investment necessary to switch over the huge established infrastructure without substantial government intervention.
No, I'm not talking about corn ethanol here, so please stop the silly arguments about how ethanol is inefficient - making it from corn is just silly. There are lots of cheap, far more easily harvested cellose-based plant products that can be broken down with slightly more effort into ethanol, and could provide us with a cheap, plentiful, and substantially more efficient means of storing and transporting biological energy to power our big ole' gas guzzlers.
This is a substantially more realistic and cost effective solution than hydrogen, and it doesn't require us to build massive amounts of new infrastructure (just a limited number of bioethanol plants) or a totally new kind of transportation and distribution network to handle hydrogen. Ethanol is stable, easy to transport, and holds up quite well to most abuse (well, except the drinking kind). It still takes a lot of cellosic material to make a gallon of bioethanol, but it's a lot less than went into that gallon of gas - it's just that the input of biological material happens in the here and now instead of millions of years ago - so we have to bear the cost ourselves. But it's renewable, predictable, and would remove the sick political imperatives behind the distribution and availability of fossil fuels. As an added bonus, no more terrorists.
Sorry, that page's arguments don't make sense. It basically argues that developing for the web is empowering for users and makes for more profitable software development, whereas developing thick client applications is disempowering for users and makes for less profitable software for developers. Oh yeah, unless you write server side Unix code, in which case whatever you do is good.
Uh, whatever happened to using the right tool for the right job and making sensible engineering and business tradeoffs? Some applications are amenable to delivery over the web, and many are not. Richer, more powerful GUIs are right for some applications, whereas they just add unnecessary cost, complexity and support issues for others. Nobody has come up with a viable web-based office suite, and they won't (subject to current definitions of "the web"). Nobody has come up with viable 3D graphics applications for the web - and they won't (delivery into IE-only plugins notwithstanding - just having your app run in a browser "shell" doesn't make it a web application).
Writing Win32 GUI applications may suck, but that's the biggest desktop market right now, and if you need to create applications that run on people's desktops, you won't make much money if you insist that you won't be a "sharecropper".
Okay, do you want to go around explaining this to Joe Sixpack, your grandmother and other computer users who don't know shit? Just like "hacker" means something different to them than it does to you, "spyware" has come to be used in the broad sense as synonymous with malware (probably because "malware" and "scumware" are mouthfuls and "crapware" is too dirty sounding).
This has gotta be the post of the day. Seriously, these guys can go fuck up a tree if they don't want to be called spyware - anything installed against your wishes that does shit to your computer you don't want done is spyware, plain and simple.
It makes all of us who try to make a living selling software and giving people stuff they actually enjoy and want to use look bad to imply that this shit is in the same category.
Your theory about bouncing is interesting. I realize that much of the time, headers may be forged, and bounces may go to bad places. On other occasions, that doesn't seem to be the place. However, my (admittedly non-scientific) study showed that if I (A) never opened spam as HTML mail, thereby loading images and the like to confirm email addresses and (B) bounce spam mail back to the source, be it correct, or some unfortunate person who got spoofed (and I do feel for them). The results of my experiment are that I get about 1/10th the volume of spam now that I did a few months ago.
Maybe it's just chance, but I'm going to keep bouncing spam - if it's some poor, unfortunate shlub, he's already been inundated, and his email account has been toasted. But it lowers my spam volume and solves a long term problem for me, which is wasting my time and energy dealing with a huge volume of spam.
After reading the article again, I still don't know how you extracted that information from it. To quote:
What AT&T is asking is for you to help AT&T to restrict incoming mail to just our known and trusted sources (e.g., business partners, clients and customers). Therefore, we need to know which IP address(es) are used by your outbound e-mail service so we can selectively permit them. Please send this information to the following e-mail address (rm-antiattspam@ems.att.com).
I suppose this could be read several ways, but everybody else at least seemed to read it the way I did. Maybe you're right, but it certainly doesn't mean we're all fucktards, it means the AT&T people who wrote this email are fucktards.
So if each big company decides to do this, they will all end up with slightly different lists of whitelisted SMTP servers. The Internet will degenerate into a fragmented, unreliable system where you never know who will receive your email. In fact, you'll be strong armed into using particular ISPs and using email addresses like shithead@att.net in order to get your email through to anybody. The Internet is thereby de-democratized and rolled back 10 years.
This is really a lose-lose situation and it's disappointing to see this. If there's going to be a concept of trusted mail servers, we need to use a technological solution that allows easy, open, and transferable trusted participation in the network - maybe for once an application where a web-of-trust would actually function. Even the current system with centralized, subscription-based blackhole lists is far better - at least you only have 5-10 different places to go if you end up on somebody's shit list.
In the dark world of the future you'll have to fight your way through bureaucracy and stupid sysadmins (and yes, the vast majority of sysadmins are fucking idiots, though I know that's not a popular opinion around here) for each and every company, organization or domain you want to send email to. That sounds like an infeasible, unmaintainable system to me.
Personally, I find the spam filtering on my fastmail (www.fastmail.fm) account to be incredibly reliable and effective, and I've found that if I bounce back every piece of true spam I get, over a few weeks or months, my rate of incoming spam seems to decrease substantially. We can do better, and we will beat the spammers, but we don't need to throw out the baby with the bathwater.
And you can hire scientists for nothing in Soviet Russia (err... I mean Russia).
Welcome to the globalized economy, comrade. It's gonna take a lot of protectionism to keep things this way for a long time because money flows fast and easy in this world. Witness Zimbabwe - screw over the white farmers, abolish property rights, and watch the investment dollars run away and ruin your economy in less than 2 years. Who didn't predict that one?
Publishers and drug companies aren't exempt from the laws of supply and demand. The drug companies have the FDA and legal scare tactics to protect their monopolies, but unless you start bundling EULAs with textbooks, it's gonna be pretty hard to keep people from doing this.
For MANY, MANY complicated applications that rely on intense user interaction, and/or frequently updating real-time data feeds, HTTP and HTML are simply the wrong tools. I think the real problem is the terminology "business IT" types use makes no fucking sense.
What the hell is "client/server"? Well, I think they mean crappy, old-fashioned middleware stuff that communicates directly with a database but has no ability to interact with other electronic systems.
My old company built electronic trading systems that supported thick client trading GUIs and web GUIs. We built our backend systems as high speed, message-based server apps that processed large order volumes asynchronously, and handled all the database interaction. The GUIs, of whatever sort, had an API expressed as a set of messages with which they interacted with the server apps - it didn't matter if it was the web interface, a thick client trading app, or another piece of software. I guess this would be called "n-tier" today, but to me, the term "n-tier" means awful, slow EJB system.
Oh well, I wish somebody would clean up this terminology and categorize networked application architecture in a way that made sense to somebody with a technical clue, because the current terminology sucks.
In this case it's because it's for a family member, rather than for myself, and she "isn't a Mac person" and doesn't want to have to learn to use a Mac. I know, I know, it's not really a great reason, but you can't dictate to people that they change their ways - I'm not interested in being an OS evangelist, I just want to find a decent piece of hardware.
Okay, looks pretty good. Right now, I love my 15.4" widescreen Dell Inspiron 8500, but I'm looking for another laptop, something more transportable (5 pound range is fine, but that needs to include CD-RW/DVD driver, 6-7 pounds is really too much).
This doesn't need to be a powerhouse, or a desktop replacement. But I don't want a 2 pound flimsy thing that requires an external CD/DVD drive and costs 2500 from Sony. This Panasonic looks mighty close to what I'm looking for, but I wish it weren't 2200 dollars - I think I should be able to find what I'm looking for in the 1500-1700 dollar range.
Also, 3 year warranty is an absolute must, and Dell-style service (in home) would be really nice.
Yeah, I know, you could tell me to just Google around, but I've tried that and can't seem to find anything. Also, don't tell me to look at the iBook, that doesn't fit the bill for my purposes. Any suggestions are much appreciated, I can't believe I'm the _ONLY_ person out there who doesn't want either a huge desktop replacement or to spend 2500 on an overpriced laptop that breaks in less than a year (EVERY PCG-Z series Vaio I've ever seen breaks or fails completely in about a year of moderate use).
Well, for one, the cost per kilowatt-hour of electricity generated from traditional photovoltaic cells is still nowhere near competitive with standard line power generated mostly by coal, with some oil, nuclear and hydro here in the ole' USA. PV technology seems to improve here and there, and there are always some companies investing in it, but we just haven't seen anything (yet) at the production stage that is cost competitive when you amortize the costs of the cells over their expected lifespan.
Or it could just be a massive right-wing conspiracy to keep us all oppressed, what do I know.
As for wind, we are building out wind infrastructure in some areas - NIMBY (not in my backyard) is a big problem with this, but I agree that the offshore angle would be an interesting one to pursue further.
This makes no sense. PHP is very useful in many real world applications. I would say it's great for low and moderate volume web-based ordering/purchasing/content systems. The key is these had better be systems with relative low per-transaction value. I would definitely use PHP to build a system that 1000s to 10s of thousands of users a day used casually, and bought and sold stuff on, assuming the basic needs of sticking orders in databases, sending them off for credit card processing, and doing stuff with return results.
Now, if a system needs to do more complex things, like a financial order processing system with complex transactional logic and the need to integrate with lots of other systems and be responsive, scaleable, and have very well defined behavior in all failure modes because the per-transaction value is potentially hundreds of thousands of dollars, then I would (and have) definitely use something based on Java (though I don't think there's enough money to get me to touch J2EE again).
But that doesn't by any means imply that PHP is useless. The applications just happen to be different.
There were two possible outcomes from this study. The first was that it showed that praying had a significant, statistically repeatable effect on outcomes. In that case, these scientists would have accomplished what humanity has been trying to figure out since we developed sentience - is there a God, and does he care about me? The other possible outcome was that the results were statistically insignificant to nil, showing that praying didn't matter.
In the first case, life would suddenly change its meaning entirely. All men and women of logic and reason would suddenly have no choice but to accept religion and pray to God. In fact, free will would rather lose its meaning. What choice is there to make? If you've already seen it proven beyond a reasonable doubt that illness is healed by prayer, everyone would pray. "Belief" and "faith" would cease to be meaningful words - you would no longer "believe" in God, you would simply make requests, demands or entreaties of him. Only the most irrational and stubborn of people would insist on active disbelief in a world in which you could trivially prove God's existed and interceded on behalf of prayer.
In the other outcome, we still don't know shit about the meaning of life and we have neither proved nor disproved anything. Either God is more intelligent than the "scientists" who crafted this study and foresaw the first possible outcome, thereby undermining the experiment itself (and this wouldn't be too hard for an omniscient God too do). Or there is no God.
Thus, we find ourselves right back where we were before - a world filled with scientific certainties and philosophical and moral vagueries, where right and wrong have to determined by our own minds and hearts, whether we believe or have faith in a God, various books written by those claiming to know this God, and so on.
I don't think this is a shocker to anybody who's moderately acquainted with the basic tenants of modern science and theology.
Slashdot Mirror
This kind of attitude is repugnant, and I'm not clear why it's so prevalent on Slashdot. I love XFree86, it was a great product for it's day, and for a period of time I have used Enlightenment, Gnome and KDE as my desktop environments, all running on top of good ol' XFree. However, in the last several years, recent versions of Windows running on modern hardware are simply far more responsive subjectively (and yes, subjective responsiveness is the most important issue from a user interface and human factors perspective, not raw primitive throughput, where we all know X is great) and have better UI consistency at the widget level (is it great? no, if you want great consistency, you have to use Mac).
Definitely, which is why you shouldn't leave a static image on it at all. Something more visually interesting is more appropriate for the medium anyway.
Yes, we do get a substantial number of people interested in doing this, and running our beautiful 3D screensavers on a 40-something inch LCD or plasma display looks absolutely amazing. We did a display at SIGGRAPH and at a party here in New York recently, and people can't help staring. If you already have the display, we can set it up for you on a stock small-form-factor PC (our installation work is all custom to-order, so drop us a line), or feel free to roll your own with our 20 dollar screen toy/screensaver.
Face it, X is not goddamned Speedy Gonzalez, and everybody suggesting that it is needs to try it for themselves running decent, modern apps on a real desktop environment and stop whining "it's not X's fault, it's GNOME/KDE/Gtk/Qt/whatever else that uses X - if you just used ugly old Xlib apps and handrolled your own Xlib code, it would be uber-fast". Y Windows definitely has the right idea - combine the toolkit and the windowing system to provide decent UI consistency and potential for substantially better performance, and improved overall maintainability and distribution of applications, which are now written to a higher level API, not bundled with lots of toolkit library dependencies out the wazoo.
Well, because that's incredibly inefficient, doesn't lend itself to standardization of applications, doesn't lend itself to networked usage, makes it hard to change or update anything at a system-wide level to reflect changes in technology over time (instead, every application has to be rebuilt and recompiled using the latest, greatest, libraries). You're right, it's the way XFree86 is going, but it's definitely not the right way (I realize you were probably being sarcastic, but I've seen a lot of that attitude expressed sincerely on Slashdot, blindly defending the X model and XFree86).
For example, most GUI toolkits. Usually, you follow the examples and tutorials as a model, you read through the API docs, and you can build a system that works pretty well. Even many other kinds of enterprise software infrastructure - take TIB Rendezvous, or similar messaging systems - I've written apps with many of them that scale, are efficient and work well on the first try.
I've seen several EJB apps written, and worked on a few myself, and you can read all the damned API docs, follow Sun's examples, read your app server documentation, and so on, and still, you just shoot yourself in the foot. This isn't the first book on patterns and anti-patterns of EJB usage, it's the umpteenth. Why? Because the EJB model was so poorly thought out prior to its implementation that if you follow the specs and build the kind of system they _seem_ to want you to build, it just doesn't work.
Instead you need to have built 10 systems that don't work before you have a clue how to make one that doesn't. Frankly, it seems to me like more trouble than it's worth for what you get (which is basically transaction-aware objects, at least based on my knowledge from the EJB 1.1 era). If you just use session beans, if you don't use entity beans, if you don't do distributed transactions, if you don't use stateful session beans... then you can build an app that works.
Great. I think the J2EE APIs have a lot of great, great stuff in them, but EJB just tweaks me out. Why the hell didn't somebody try using this hunk-a-junk before they released their 1.0 spec, or maybe their 1.1 spec, or howzabout the 2.0 spec? Maybe things are better these days, but if your API looks like it's supposed to provide a pattern for enterprise database applications, shouldn't it actually do that, or somehow redefine what the hell it's really supposed to be for?
We have well over a million FFVs on the road in the US already, but very few people even realize that they have them, because few manufacturers actually market the fact that their cars have FFV engines. They simply make them with FFVs for the tax breaks they get making reduced emission or alternative fuel vehicles. Unfortunately, the result is that very few people outside of certain areas (like parts of the midwest where corn ethanol is produced in bulk) know about this, or ever use ethanol in their cars.
The nice thing about ethanol is that it's quite efficient and inexpensive to make, relative to the biodiesels and other lipid-derived heavy fuels that can also be made from biological sources. The amount of government subsidy and capital investment required to transition to ethanol is tiny compared to switching to hydrogen, or to making biodiesel or similar fuels cost effective (see the current numbers on biodiesel from DOE and NREL - it is still a factor of 2-3 away from cost competiveness, whereas bioethanol is perhaps 20%-30% away from cost-competitiveness).
I'll start you off with this overview link. Then I'll direct you here to read an energy security justification of the Biofuels research program at the DOE. If you are interested in reading a technical and economic assessment of one such program in this area, I encourage you to read this report from the NREL (big PDF warning) which has lots and lots of numbers to backup a feasibility analysis of large scale bioethanol production. Search around the ott.doe.gov/biofuels page, you'll find tons and tons more research and useful information, and hopefully you won't think this is just "snake oil".
My point in my first post was simply that alternatives exist. I don't really give a shit about how many tons of this or that are used if it makes sense economically, politically and environmentally (or rather, I think environmental impact should be factored into overall lifecycle cost analysis). In terms of arguing that oil is cheaper, it's only cheaper when you ignore the sociopolitical impact and costs that are hidden at the pump because they are incurred at the federal government level, in the way your taxpayer dollars and the wealth of the First World is allocated to defense spending.
No, I'm not talking about corn ethanol here, so please stop the silly arguments about how ethanol is inefficient - making it from corn is just silly. There are lots of cheap, far more easily harvested cellose-based plant products that can be broken down with slightly more effort into ethanol, and could provide us with a cheap, plentiful, and substantially more efficient means of storing and transporting biological energy to power our big ole' gas guzzlers.
This is a substantially more realistic and cost effective solution than hydrogen, and it doesn't require us to build massive amounts of new infrastructure (just a limited number of bioethanol plants) or a totally new kind of transportation and distribution network to handle hydrogen. Ethanol is stable, easy to transport, and holds up quite well to most abuse (well, except the drinking kind). It still takes a lot of cellosic material to make a gallon of bioethanol, but it's a lot less than went into that gallon of gas - it's just that the input of biological material happens in the here and now instead of millions of years ago - so we have to bear the cost ourselves. But it's renewable, predictable, and would remove the sick political imperatives behind the distribution and availability of fossil fuels. As an added bonus, no more terrorists.
Uh, whatever happened to using the right tool for the right job and making sensible engineering and business tradeoffs? Some applications are amenable to delivery over the web, and many are not. Richer, more powerful GUIs are right for some applications, whereas they just add unnecessary cost, complexity and support issues for others. Nobody has come up with a viable web-based office suite, and they won't (subject to current definitions of "the web"). Nobody has come up with viable 3D graphics applications for the web - and they won't (delivery into IE-only plugins notwithstanding - just having your app run in a browser "shell" doesn't make it a web application).
Writing Win32 GUI applications may suck, but that's the biggest desktop market right now, and if you need to create applications that run on people's desktops, you won't make much money if you insist that you won't be a "sharecropper".
Okay, do you want to go around explaining this to Joe Sixpack, your grandmother and other computer users who don't know shit? Just like "hacker" means something different to them than it does to you, "spyware" has come to be used in the broad sense as synonymous with malware (probably because "malware" and "scumware" are mouthfuls and "crapware" is too dirty sounding).
It makes all of us who try to make a living selling software and giving people stuff they actually enjoy and want to use look bad to imply that this shit is in the same category.
Maybe it's just chance, but I'm going to keep bouncing spam - if it's some poor, unfortunate shlub, he's already been inundated, and his email account has been toasted. But it lowers my spam volume and solves a long term problem for me, which is wasting my time and energy dealing with a huge volume of spam.
To quote:
I suppose this could be read several ways, but everybody else at least seemed to read it the way I did. Maybe you're right, but it certainly doesn't mean we're all fucktards, it means the AT&T people who wrote this email are fucktards.
This is really a lose-lose situation and it's disappointing to see this. If there's going to be a concept of trusted mail servers, we need to use a technological solution that allows easy, open, and transferable trusted participation in the network - maybe for once an application where a web-of-trust would actually function. Even the current system with centralized, subscription-based blackhole lists is far better - at least you only have 5-10 different places to go if you end up on somebody's shit list.
In the dark world of the future you'll have to fight your way through bureaucracy and stupid sysadmins (and yes, the vast majority of sysadmins are fucking idiots, though I know that's not a popular opinion around here) for each and every company, organization or domain you want to send email to. That sounds like an infeasible, unmaintainable system to me.
Personally, I find the spam filtering on my fastmail (www.fastmail.fm) account to be incredibly reliable and effective, and I've found that if I bounce back every piece of true spam I get, over a few weeks or months, my rate of incoming spam seems to decrease substantially. We can do better, and we will beat the spammers, but we don't need to throw out the baby with the bathwater.
Manufacturing is cheaper in China.
And you can hire scientists for nothing in Soviet Russia (err... I mean Russia).
Welcome to the globalized economy, comrade. It's gonna take a lot of protectionism to keep things this way for a long time because money flows fast and easy in this world. Witness Zimbabwe - screw over the white farmers, abolish property rights, and watch the investment dollars run away and ruin your economy in less than 2 years. Who didn't predict that one?
Publishers and drug companies aren't exempt from the laws of supply and demand. The drug companies have the FDA and legal scare tactics to protect their monopolies, but unless you start bundling EULAs with textbooks, it's gonna be pretty hard to keep people from doing this.
What the hell is "client/server"? Well, I think they mean crappy, old-fashioned middleware stuff that communicates directly with a database but has no ability to interact with other electronic systems.
My old company built electronic trading systems that supported thick client trading GUIs and web GUIs. We built our backend systems as high speed, message-based server apps that processed large order volumes asynchronously, and handled all the database interaction. The GUIs, of whatever sort, had an API expressed as a set of messages with which they interacted with the server apps - it didn't matter if it was the web interface, a thick client trading app, or another piece of software. I guess this would be called "n-tier" today, but to me, the term "n-tier" means awful, slow EJB system.
Oh well, I wish somebody would clean up this terminology and categorize networked application architecture in a way that made sense to somebody with a technical clue, because the current terminology sucks.
In this case it's because it's for a family member, rather than for myself, and she "isn't a Mac person" and doesn't want to have to learn to use a Mac. I know, I know, it's not really a great reason, but you can't dictate to people that they change their ways - I'm not interested in being an OS evangelist, I just want to find a decent piece of hardware.
This doesn't need to be a powerhouse, or a desktop replacement. But I don't want a 2 pound flimsy thing that requires an external CD/DVD drive and costs 2500 from Sony. This Panasonic looks mighty close to what I'm looking for, but I wish it weren't 2200 dollars - I think I should be able to find what I'm looking for in the 1500-1700 dollar range.
Also, 3 year warranty is an absolute must, and Dell-style service (in home) would be really nice.
Yeah, I know, you could tell me to just Google around, but I've tried that and can't seem to find anything. Also, don't tell me to look at the iBook, that doesn't fit the bill for my purposes. Any suggestions are much appreciated, I can't believe I'm the _ONLY_ person out there who doesn't want either a huge desktop replacement or to spend 2500 on an overpriced laptop that breaks in less than a year (EVERY PCG-Z series Vaio I've ever seen breaks or fails completely in about a year of moderate use).
Or it could just be a massive right-wing conspiracy to keep us all oppressed, what do I know.
As for wind, we are building out wind infrastructure in some areas - NIMBY (not in my backyard) is a big problem with this, but I agree that the offshore angle would be an interesting one to pursue further.
This makes no sense. PHP is very useful in many real world applications. I would say it's great for low and moderate volume web-based ordering/purchasing/content systems. The key is these had better be systems with relative low per-transaction value. I would definitely use PHP to build a system that 1000s to 10s of thousands of users a day used casually, and bought and sold stuff on, assuming the basic needs of sticking orders in databases, sending them off for credit card processing, and doing stuff with return results.
Now, if a system needs to do more complex things, like a financial order processing system with complex transactional logic and the need to integrate with lots of other systems and be responsive, scaleable, and have very well defined behavior in all failure modes because the per-transaction value is potentially hundreds of thousands of dollars, then I would (and have) definitely use something based on Java (though I don't think there's enough money to get me to touch J2EE again).
But that doesn't by any means imply that PHP is useless. The applications just happen to be different.
In the first case, life would suddenly change its meaning entirely. All men and women of logic and reason would suddenly have no choice but to accept religion and pray to God. In fact, free will would rather lose its meaning. What choice is there to make? If you've already seen it proven beyond a reasonable doubt that illness is healed by prayer, everyone would pray. "Belief" and "faith" would cease to be meaningful words - you would no longer "believe" in God, you would simply make requests, demands or entreaties of him. Only the most irrational and stubborn of people would insist on active disbelief in a world in which you could trivially prove God's existed and interceded on behalf of prayer.
In the other outcome, we still don't know shit about the meaning of life and we have neither proved nor disproved anything. Either God is more intelligent than the "scientists" who crafted this study and foresaw the first possible outcome, thereby undermining the experiment itself (and this wouldn't be too hard for an omniscient God too do). Or there is no God.
Thus, we find ourselves right back where we were before - a world filled with scientific certainties and philosophical and moral vagueries, where right and wrong have to determined by our own minds and hearts, whether we believe or have faith in a God, various books written by those claiming to know this God, and so on.
I don't think this is a shocker to anybody who's moderately acquainted with the basic tenants of modern science and theology.
That's what he means by "faith". Go read "Fear and Trembling" and spend a while thinking about what it means. Then see if your head explodes from it.