5. As a deception, sometimes the oiler is in the center of the formation
Ummm... no. While the carrier's a nuke, the planes on it aren't, and high tempo ops chew through JP-5 like nobody's business. Likewise, while some of the ships the carrier is relying on for AAW/ASW are nuclear powered, the vast majority are not.
At least when I left the Navy, doctine (fairly old, established and time tested) was that in a typical carrier formation, the oiler and the carrier were both critical, high-value assets... loosing either one would seriously degrade the effectiveness of the entire task force. Of course, it was also doctrine that such formations kept a few miles seperation between the oiler and other ships, if at all possible... I'm sure you can imagine why:-/
As LarryBoy noted, that would require that God lie.
Hmm. No, I don't think I agree... the way I see it, God's choice to not give us complete revelation about His actions and plans doesn't fall into the category of a falsehood. I can see where that's a subtle distinction, though, and I may be splitting hairs to finely (or attempting to split hairs that never existed in the first place.) Gives me something new to study, I guess.
I will wholeheartedly agree with your statement about mistranslations/misinterpretations, though. IMHO, a majority of the "issues" folks have with the Bible are mountains raised up from molehills.
I'm a metallurgist, a computer programmer, and I spend a good bit of time reading about quantum physics, fractal geometry and astronomy becuase I like to. I'm also a fundamentalist Christian, and read and study the Bible, something else I also enjoy.
I don't claim to understand the mind of God. I'm personally comfortable with the idea that the God I worship - the one that I believe to be an omnipotent, omnipowerful being that exists outside of time and space - had his own reasons for creating, in six days, a universe that looks and in all respects acts as if it were billions of years old. Why? Maybe to give us something to study for a few thousand years. Maybe just to give us something to look at and wonder about in the night sky. In any case, I'm happy to study science on one hand, and argue theology on the other, without feeling the overwhleming need to reconcile what I see as two fundamentally irreconcilable subjects (something both "creationists" and "evolutionists" seem to think is absolutely essential, for some reason.)
A lot of Niven's Known Space stories would work, but Hollywood would probably warp them into special effects bonanzas. Pulling together a couple of the Draco tavern tales might work, though.... and the Gil Hamilton stories would work really well (near enough future that you don't need to explain everything, enough SF to keep things interesting.).
All in all, though, I'd much rather see something from Clifford Simak's works done instead... "Mastadonia", "Cemetary World", or... mmmm... "The Big Front Yard". (IMDB does list Anomaliya, based on "All Flesh is Grass". Wonder how good that is.)
(And what the @*&!^#*&? happened to the "Watchmen" movie?)
Years ago, I had a Mac extension (called IceTEA, I think) that hooked into the Mac textedit routines. It looked for text strings like http://, ftp://, mailto:, foo@bar.com, etc. and caused the text engine to display them as active hyperlinks.
With IceTEA installed, any text field that use the textedit package (which was just about everything except MS Word) could contain a hyperlink. Weird, and wonderful... and an excellent example of why arguments against deep linking are just Plain Old Stupid (POS) ideas.
But the real bear is the compilation error messages, which can be pages long, and ultimately completely unreadable.
There are a handful of utilities that are designed to "translate" these types of error messages, and produce something human-readable (or at least developer-readable.)
I suspect that compiler writers will eventually start using these same sort of techniques to present usable error messages for STL constructs. Hmm... might actually be interesting to do this for GCC.
Ad-Aware is up front about this: it's a utility designed solely for finding, and removing, certain pieces of software. A specialized "rm", if you will. Certainly no different from Clean Sweep or other similar products, it is designed to allow the owner or operator of the computer to decide what files should be removed.
RadLight, on the other hand, has an entirely unrelated purpose. If it's removing random files without asking the user for permission to do so, it's either (a) buggy, (b) malicious. I'd argue that their mention of this in the EULA (as opposed to README or BUGS or a similar file) indicates that this was intentional on their part, which IMHO moves them from the category of "spyware" and into the category of "trojan".
I've got a half-finishd Macquarium built out of my wife's old Plus. Never got around to finishing up the glass. I really need to get in done sometime soon, particularly since my daughter would love it.:-)
I'd do the same thing to my SE/30, but (wonder of wonders) it still works (and still gets fired up every couple of years, just for nostalgia's sake.)
...neither Ximian nor anyone else has plans to clone the rest (Windows Forms, Dotnet ADO etc.)
FUD.
It took me just a few moments browsing through the mono project plan to come up with this:
Using existing components from GNOME.
Our current plan is to implement the GUI tools on top of Gtk+. The only obstacle here is that applications from Windows might expect to be able to pull the HWND property from the widgets and use PInvoke to call Windows functions.
Class Library and Win32 dependencies.
There are a few spots where the Win32 foundation is exposed to the class library (for example, the HDC and HWND properties in the GDI+). Casual inspection suggests that these can be safely mapped to Gdk's GC and GdkWindow pointers without breaking anything.
The only drawback is that support for PInvoke of Win32 code won't be available. An alternate solution would be to use portions of Wine, or even to use Wine as our toolkit.
Initial GDI+ and WinForms implementation
The initial implementation will use Gtk+ as the underlying toolkit. Since GTK+ has already been ported to many windowing systems other than X (including frame buffer, Win32, and BeOS) its use should cover most applications for most users.
Database access
We will implement ADO.NET functionality by reusing GNOME-DB. This is an ideal choice, since GNOME-DB was implemented precisely to provide an ADO-like system for GNOME.
Asimov? Limited? You mean then gent who's turned out hundreds of nonfiction works on everything from astronomy to religion? The guy who seemed equally comfortable writing a 3-page short story and a 300 page novel? The fellow who wrote something under just about ever conceivable SF sub-genre you can name?
Considering the linux kernel uses non standardised GCC extensions...i doubt it.
At the MS PDC ~3-4 years ago, the VC development team was talking about giving "providers" the ability to integrate into the VC compiler. This would have given VC++ the same extensibility as C# (where you can define your own custom attributes, and write code that generates the IL for that attribute.)
My memory of this is, admitedly, hazy, but as I recall, this caused quite a stir (both for and against the idea.) Why bring it up? Well... MS has obviously at least thought about this over the past few years (both with C# and C++). If they really wanted to snarf market share from other compilers - including gcc - then providing the ability for end users to add arbitrary language extensions to VC++ (and minimize porting time) would be a pretty significant feature.
And, finally... if they did that, then you'd at least get around the problem non-standard gcc extensions in the kernel code. I'm sure many other problems would manifest themselves, though.
After a while most people would realise they can achieve faster results by going direct to the config file...
Please - don't make the mistake of assuming that every user will eventually become a config file hacking guru. There are plenty of casual users who don't feel the need to grok Yet Another Config File Format just so they can figure out how to enable or disable 'Feature X' in whatever software they're using at the moment.
Any UI - graphical, command-line, or config file - can become an impediment under the right circumstances. If you have 500 servers to administer, a GUI that only works with one server at a time is an impediment. If you only use a tool once in a blue moon, a complex command line interface means essentially having to relearn the tool every time you go to use it. If you don't speak Enlgish, then a lot of "plain text" config file formats are as clear as mud.
IMHO, the best UI's are those that:
Start with a clean configuration file format;
Build a binary interface that is intended to read/write that format; and
Use that library to build command-line and GUI tools for manipulating the config files.
In this case, you get the best of all worlds - a sane config file syntax, a supported and endorsed interface for altering config files, and tools that both CLI and GUI users can feel comfortable with.
You know, this would be funny, except that the few contacts I've had with folks at RH have convinced me that they have a good number of technical folks who would quite cheerfully screw over their company just for the chance to tell someone how stupid they are.
You know who I mean... the type who would be on the other end of this conversation:
Customer: Hmm, you've made a pretty good case... what about scheduling groupware? We're using Exchange right now, and we'd like... RH Guru: Then run Windows, looser. Customer: Excuse me? RH Guru: You mean you've never set up a distributed calendaring system using ssh and perl? What kind of company are you? Customer: Um, an insurance company... RH Guru: Then what the HELL do you think you're doing, touching our software? Customer: Uhhh... RH Guru: Come talk to us when you've bothered to write a few device drivers. Frickin' loosers...
My wife and I have ditched our previous cell phones for Tracfones. This year, I've spent ~$200 for 400 minutes of airtime - around $0.50/min (my usage pattern with my cell phone makes that a better deal than paying $420/year for unlimited minutes). So in that respect, it's comparable to the Hop-On.
On the other hand, unlike the Hop-On, my Tracfone is a real, honest-to-goodness, rechargeable Nokia (and a fairly nice one at that.) So you have to wonder at the Hop-On buisness model... provide less value than an established competitor, for the same price? I thought the dot-com era demonstrated exactly where this type of thinking would take you.
The goal of good design, imnsho, is to avoid refactoring.
Hmm. I'd have to disagree - I'd argue that refactoring is not a replacement for good design, but an adjunct to be used in those places where the design, for whatever reason, is determined to be inappropriate.
This can happen for any nubmer of reasons external to the design itself. If you're working on a 2-year project, and your target marketplace undergoes an economic upheaval a year into development... well, you might end up re-evaluating your original design. Or your implementation may expose a bug in a 3rd-party application or even the operating system iteself that you cannot fix, cannot get fixed, and therefore have to work around (by changing the design, if you happen to be very unlucky. We were.) Finally, of course, the design my have been produced by someone or some group who either just missed some subtle or not-so-subtle points when producing the design.
These things happen - I've seen both, at more than one company. The designs were good, but they were created with certain assumptions. IMHO, this is where refactoring is valuable. If you have designed and implemented your code with refactoring in mind, you are essentially saying that one of the design assumptions you have made is that the design may need to be changed at some point if one of the other assumptions were wrong.. That's not "bad design" - if anything, it's an example of good risk management.
So this will lead to something like... the back of the software box listing the exact system requirments that the software is good for (and liable on) and if you use it outside of that environment, you're no longer using the software as it was intended.
I can just see it now:
Tech: I'm sorry, sir, but we can't support you, as you're using our software on an unsupported hardware configuration. Customer: What do you mena, "unsupported"? I've got the same memory, hard disk, processor... Tech: Your system does not include a Washington World Wide Wonderfulware USB Series 1 mouse. We only support systems using one of our own mice, sir, in order to avoid potential driver conflicts.
Customer: All right! I'll get one of your mice, and hook it up... will you support my configuration then?
Tech: Certainly, sir. Let me transfer you to sales... Sales: Washington World Wide Wonderfulware sales. May I help you? Customer: I'd like to order a USB, uh, series 1 mouse, please. Sales: Very well, sir. That will be one million dollars. Mu-ha-ha-ha-ha!
Mmmmm. Whatever it is that you're smoking, can I have some, too?
Hacking on NTFS certainly is not illegal. NTFS is a file system. It's a way of storing data on a physical medium. Presuming you own the hard drive that you formatted as NTFS, there is nothing that prevents you from doing whatever you want with it - burning it, using it as a frisbee, or designing some random program or driver to read and write to an NTFS partition.
Don't believe me? There are a number of NTFS drivers that are freely available for DOS, Win95, Linux, *BSD, OS/2; various 3rd party (including open source) software programs for defragmenting or recovering data from NTFS partitions... the list goes on. If it were illegal to do this, as you assert, I would venture to guess that any and all of these projects and products would have been shut down by Microsoft (or whoever holds the appropriate patents) a loooooong time ago.
Now, if you were to get hold of the NTFS source code from Microsoft, and hack on that, and then distribute it, sure, you'd probably be breaking a few clauses in your NDAs and a random sampling of federal, state, and local laws. Is that what you meant?
What is a far better solution is for groups of citizens who want to end sprawl, such as yourself, combined with the rich loud mouths who critize people who live in sprawl, to actually get together and purchase up unspoiled suburban land and it put into permanent unbreakable land trusts.
Here in PA, there's a program called "Clean & Green". If you own more than 10 acres of land, you can register under this program and get some significant property tax breaks. The land may not be developed while it's enrolled in the program; and in order to disenroll, you need to pay up to seven years back taxes. Ouch. There are other programs where the state essentially buys the right to develop the property from the landowner. If anyone ever decides they wish to develop that land, then they need to both buy the property and buy the development rights back from the state (asuming that the state is willing to seel thsoe rights.)
The point is, these are fairly popular programs in PA with the landholders themselves. No need to form citizens groups to buy up the land, or anything like that... just make it more profitable for a landowner to keep their land undeveloped. Right now, the only reason the Clean green program isn't massively popular in near-suburban areas of PA is that it takes two years to process the application and get your property enrolled in the program, and the application process is needlessly finicky about when you may attempt to enroll.
Just look at Linux-based distributions with a great deal of non-free code and how much they benefit from a free kernel, network code, graphical system, etc. 80% free and 20% non-free. Is that fair?
Yes, because that's what was intended. Linus set out to create a general-purpose operating system, not make a political point. It's no surprise he's succeeded at the first and failed at the later (at least, from your point of view).
If you want to use an OS that promotes the GNU political agenda, please feel free to stop using Linux and switch to HURD.
Minor correction - I realize this is an article on gcc, but my experience was with the glibc maintainers.
That said, yes, the information abou the problems and the workarounds were posted to the community of interest... a relatively minor number of folks, at least judging by the whopping number (1) of posts I found related to any of these problems:-/
Still, they've been made public in an arena where they might actually do some good. Other than that, since the work is being done for my employer, they get the say in how patches get distributed (whether we give them away willy-nilly, or only IAW the strict GPL interpretation.) I'm going to approach them about supporting/archiving Cygwin-specific cross-compiler patches on a public portion of our company website.
Oh, no worries there - we're using it, all right, along with a couple of others that probably won't be submitted because of this attitude. What blows is trying to give someone something out of gratitude and a sense of community, only to have them spit in your face.
Instead of being dissapointed, you should talk about it on GCC mailing lists [gnu.org] or even submit a patch.
Really? And have someone tell you to "get lost" becuase the patch you're submitting offends their political sensibilities?
But hey, at least I'm not bitter.
Re:Is it Netsafe?? Doesn't sound like it.
on
Lindows Reviewed
·
· Score: 1
Hmm. Let's see - this is refered to as a "sneak preview", and the article has lots of quotes an unnamed "insider". Could it be that, perhaps this is not the final release, and that they decided to address potential security problems after they proved (to themselves and the world at large) that they could actually do what they set out to do?
...who else here actually likes MFC, or would prefer to use it over... well, ANYTHING else?
I would. Not because I think it's well-designed, or better than QT, or anything like that. I started working with MFC 8 years ago, and I've kept up to date with it over the years, and I know how it works - the little quirks, foibles, and problems that it has; it's strengths and weaknesses. Yah, it's pretty much a sucky piece of junk, but it's a sucky piece of junk that I'm very, very familiar with. Compared to working in any other GUI environment, I'm about 10x more productive when using MFC.
That may change, at some point. I've done some work with QT, and while it seems awkward in places, it's problems defintely aren't any worse than MFC's... just different. My MFC experience causes problems, because my GUI coding habits are geared towards dealing with MFC. It's just going to take some time to get to know QT well enough that I'll be as productive with it as I am with MFC.
If that reasoning sounds weird - I mean, why in the world would I want to use something technically inferior, just because I'm familiar with it? - go back and change "MFC" to "emacs" and "QT" to "vi" (or vice versa, depending on which editor you consider inferior, of course:-)
Slashdot Mirror
Ummm... no. While the carrier's a nuke, the planes on it aren't, and high tempo ops chew through JP-5 like nobody's business. Likewise, while some of the ships the carrier is relying on for AAW/ASW are nuclear powered, the vast majority are not.
At least when I left the Navy, doctine (fairly old, established and time tested) was that in a typical carrier formation, the oiler and the carrier were both critical, high-value assets... loosing either one would seriously degrade the effectiveness of the entire task force. Of course, it was also doctrine that such formations kept a few miles seperation between the oiler and other ships, if at all possible... I'm sure you can imagine why :-/
Hmm. No, I don't think I agree... the way I see it, God's choice to not give us complete revelation about His actions and plans doesn't fall into the category of a falsehood. I can see where that's a subtle distinction, though, and I may be splitting hairs to finely (or attempting to split hairs that never existed in the first place.) Gives me something new to study, I guess.
I will wholeheartedly agree with your statement about mistranslations/misinterpretations, though. IMHO, a majority of the "issues" folks have with the Bible are mountains raised up from molehills.
I'm a metallurgist, a computer programmer, and I spend a good bit of time reading about quantum physics, fractal geometry and astronomy becuase I like to. I'm also a fundamentalist Christian, and read and study the Bible, something else I also enjoy.
I don't claim to understand the mind of God. I'm personally comfortable with the idea that the God I worship - the one that I believe to be an omnipotent, omnipowerful being that exists outside of time and space - had his own reasons for creating, in six days, a universe that looks and in all respects acts as if it were billions of years old. Why? Maybe to give us something to study for a few thousand years. Maybe just to give us something to look at and wonder about in the night sky. In any case, I'm happy to study science on one hand, and argue theology on the other, without feeling the overwhleming need to reconcile what I see as two fundamentally irreconcilable subjects (something both "creationists" and "evolutionists" seem to think is absolutely essential, for some reason.)
All in all, though, I'd much rather see something from Clifford Simak's works done instead... "Mastadonia", "Cemetary World", or... mmmm... "The Big Front Yard". (IMDB does list Anomaliya, based on "All Flesh is Grass". Wonder how good that is.)
(And what the @*&!^#*&? happened to the "Watchmen" movie?)
Years ago, I had a Mac extension (called IceTEA, I think) that hooked into the Mac textedit routines. It looked for text strings like http://, ftp://, mailto:, foo@bar.com, etc. and caused the text engine to display them as active hyperlinks.
With IceTEA installed, any text field that use the textedit package (which was just about everything except MS Word) could contain a hyperlink. Weird, and wonderful... and an excellent example of why arguments against deep linking are just Plain Old Stupid (POS) ideas.
There are a handful of utilities that are designed to "translate" these types of error messages, and produce something human-readable (or at least developer-readable.)
I suspect that compiler writers will eventually start using these same sort of techniques to present usable error messages for STL constructs. Hmm... might actually be interesting to do this for GCC.
Cool! Never thought of using acrylic... I'll ahve to take a closer look at your versions and give some thought to finishing up mine now.
RadLight, on the other hand, has an entirely unrelated purpose. If it's removing random files without asking the user for permission to do so, it's either (a) buggy, (b) malicious. I'd argue that their mention of this in the EULA (as opposed to README or BUGS or a similar file) indicates that this was intentional on their part, which IMHO moves them from the category of "spyware" and into the category of "trojan".
I've got a half-finishd Macquarium built out of my wife's old Plus. Never got around to finishing up the glass. I really need to get in done sometime soon, particularly since my daughter would love it. :-)
I'd do the same thing to my SE/30, but (wonder of wonders) it still works (and still gets fired up every couple of years, just for nostalgia's sake.)
FUD.
It took me just a few moments browsing through the mono project plan to come up with this:
Asimov? Limited? You mean then gent who's turned out hundreds of nonfiction works on everything from astronomy to religion? The guy who seemed equally comfortable writing a 3-page short story and a 300 page novel? The fellow who wrote something under just about ever conceivable SF sub-genre you can name?
Oh, yah, he's limited.
At the MS PDC ~3-4 years ago, the VC development team was talking about giving "providers" the ability to integrate into the VC compiler. This would have given VC++ the same extensibility as C# (where you can define your own custom attributes, and write code that generates the IL for that attribute.)
My memory of this is, admitedly, hazy, but as I recall, this caused quite a stir (both for and against the idea.) Why bring it up? Well... MS has obviously at least thought about this over the past few years (both with C# and C++). If they really wanted to snarf market share from other compilers - including gcc - then providing the ability for end users to add arbitrary language extensions to VC++ (and minimize porting time) would be a pretty significant feature.
And, finally... if they did that, then you'd at least get around the problem non-standard gcc extensions in the kernel code. I'm sure many other problems would manifest themselves, though.
Please - don't make the mistake of assuming that every user will eventually become a config file hacking guru. There are plenty of casual users who don't feel the need to grok Yet Another Config File Format just so they can figure out how to enable or disable 'Feature X' in whatever software they're using at the moment.
Any UI - graphical, command-line, or config file - can become an impediment under the right circumstances. If you have 500 servers to administer, a GUI that only works with one server at a time is an impediment. If you only use a tool once in a blue moon, a complex command line interface means essentially having to relearn the tool every time you go to use it. If you don't speak Enlgish, then a lot of "plain text" config file formats are as clear as mud.
IMHO, the best UI's are those that:
In this case, you get the best of all worlds - a sane config file syntax, a supported and endorsed interface for altering config files, and tools that both CLI and GUI users can feel comfortable with.
You know, this would be funny, except that the few contacts I've had with folks at RH have convinced me that they have a good number of technical folks who would quite cheerfully screw over their company just for the chance to tell someone how stupid they are.
You know who I mean... the type who would be on the other end of this conversation:
Customer: Hmm, you've made a pretty good case... what about scheduling groupware? We're using Exchange right now, and we'd like...
RH Guru: Then run Windows, looser.
Customer: Excuse me?
RH Guru: You mean you've never set up a distributed calendaring system using ssh and perl? What kind of company are you?
Customer: Um, an insurance company...
RH Guru: Then what the HELL do you think you're doing, touching our software?
Customer: Uhhh...
RH Guru: Come talk to us when you've bothered to write a few device drivers. Frickin' loosers...
*click*
My wife and I have ditched our previous cell phones for Tracfones. This year, I've spent ~$200 for 400 minutes of airtime - around $0.50/min (my usage pattern with my cell phone makes that a better deal than paying $420/year for unlimited minutes). So in that respect, it's comparable to the Hop-On.
On the other hand, unlike the Hop-On, my Tracfone is a real, honest-to-goodness, rechargeable Nokia (and a fairly nice one at that.) So you have to wonder at the Hop-On buisness model... provide less value than an established competitor, for the same price? I thought the dot-com era demonstrated exactly where this type of thinking would take you.
Hmm. I'd have to disagree - I'd argue that refactoring is not a replacement for good design, but an adjunct to be used in those places where the design, for whatever reason, is determined to be inappropriate.
This can happen for any nubmer of reasons external to the design itself. If you're working on a 2-year project, and your target marketplace undergoes an economic upheaval a year into development... well, you might end up re-evaluating your original design. Or your implementation may expose a bug in a 3rd-party application or even the operating system iteself that you cannot fix, cannot get fixed, and therefore have to work around (by changing the design, if you happen to be very unlucky. We were.) Finally, of course, the design my have been produced by someone or some group who either just missed some subtle or not-so-subtle points when producing the design.
These things happen - I've seen both, at more than one company. The designs were good, but they were created with certain assumptions. IMHO, this is where refactoring is valuable. If you have designed and implemented your code with refactoring in mind, you are essentially saying that one of the design assumptions you have made is that the design may need to be changed at some point if one of the other assumptions were wrong. . That's not "bad design" - if anything, it's an example of good risk management.
I can just see it now:
Tech: I'm sorry, sir, but we can't support you, as you're using our software on an unsupported hardware configuration.
Customer: What do you mena, "unsupported"? I've got the same memory, hard disk, processor...
Tech: Your system does not include a Washington World Wide Wonderfulware USB Series 1 mouse. We only support systems using one of our own mice, sir, in order to avoid potential driver conflicts. Customer: All right! I'll get one of your mice, and hook it up... will you support my configuration then? Tech: Certainly, sir. Let me transfer you to sales...
Sales: Washington World Wide Wonderfulware sales. May I help you?
Customer: I'd like to order a USB, uh, series 1 mouse, please.
Sales: Very well, sir. That will be one million dollars. Mu-ha-ha-ha-ha!
Mmmmm. Whatever it is that you're smoking, can I have some, too?
Hacking on NTFS certainly is not illegal. NTFS is a file system. It's a way of storing data on a physical medium. Presuming you own the hard drive that you formatted as NTFS, there is nothing that prevents you from doing whatever you want with it - burning it, using it as a frisbee, or designing some random program or driver to read and write to an NTFS partition.
Don't believe me? There are a number of NTFS drivers that are freely available for DOS, Win95, Linux, *BSD, OS/2; various 3rd party (including open source) software programs for defragmenting or recovering data from NTFS partitions... the list goes on. If it were illegal to do this, as you assert, I would venture to guess that any and all of these projects and products would have been shut down by Microsoft (or whoever holds the appropriate patents) a loooooong time ago.
Now, if you were to get hold of the NTFS source code from Microsoft, and hack on that, and then distribute it, sure, you'd probably be breaking a few clauses in your NDAs and a random sampling of federal, state, and local laws. Is that what you meant?
Here in PA, there's a program called "Clean & Green". If you own more than 10 acres of land, you can register under this program and get some significant property tax breaks. The land may not be developed while it's enrolled in the program; and in order to disenroll, you need to pay up to seven years back taxes. Ouch. There are other programs where the state essentially buys the right to develop the property from the landowner. If anyone ever decides they wish to develop that land, then they need to both buy the property and buy the development rights back from the state (asuming that the state is willing to seel thsoe rights.)
The point is, these are fairly popular programs in PA with the landholders themselves. No need to form citizens groups to buy up the land, or anything like that... just make it more profitable for a landowner to keep their land undeveloped. Right now, the only reason the Clean green program isn't massively popular in near-suburban areas of PA is that it takes two years to process the application and get your property enrolled in the program, and the application process is needlessly finicky about when you may attempt to enroll.
Yes, because that's what was intended. Linus set out to create a general-purpose operating system, not make a political point. It's no surprise he's succeeded at the first and failed at the later (at least, from your point of view).
If you want to use an OS that promotes the GNU political agenda, please feel free to stop using Linux and switch to HURD.
Minor correction - I realize this is an article on gcc, but my experience was with the glibc maintainers.
That said, yes, the information abou the problems and the workarounds were posted to the community of interest... a relatively minor number of folks, at least judging by the whopping number (1) of posts I found related to any of these problems :-/
Still, they've been made public in an arena where they might actually do some good. Other than that, since the work is being done for my employer, they get the say in how patches get distributed (whether we give them away willy-nilly, or only IAW the strict GPL interpretation.) I'm going to approach them about supporting/archiving Cygwin-specific cross-compiler patches on a public portion of our company website.
Oh, no worries there - we're using it, all right, along with a couple of others that probably won't be submitted because of this attitude. What blows is trying to give someone something out of gratitude and a sense of community, only to have them spit in your face.
Really? And have someone tell you to "get lost" becuase the patch you're submitting offends their political sensibilities?
But hey, at least I'm not bitter.
Hmm. Let's see - this is refered to as a "sneak preview", and the article has lots of quotes an unnamed "insider". Could it be that, perhaps this is not the final release, and that they decided to address potential security problems after they proved (to themselves and the world at large) that they could actually do what they set out to do?
I would. Not because I think it's well-designed, or better than QT, or anything like that. I started working with MFC 8 years ago, and I've kept up to date with it over the years, and I know how it works - the little quirks, foibles, and problems that it has; it's strengths and weaknesses. Yah, it's pretty much a sucky piece of junk, but it's a sucky piece of junk that I'm very, very familiar with. Compared to working in any other GUI environment, I'm about 10x more productive when using MFC.
That may change, at some point. I've done some work with QT, and while it seems awkward in places, it's problems defintely aren't any worse than MFC's... just different. My MFC experience causes problems, because my GUI coding habits are geared towards dealing with MFC. It's just going to take some time to get to know QT well enough that I'll be as productive with it as I am with MFC.
If that reasoning sounds weird - I mean, why in the world would I want to use something technically inferior, just because I'm familiar with it? - go back and change "MFC" to "emacs" and "QT" to "vi" (or vice versa, depending on which editor you consider inferior, of course :-)