Keep the current keyboard, mouse and monitor, replace the PC with a 1 gig RAM/80 GB HD dual-core mini, and you're "Mac-ified" for $724.00. You can go to 120 GB HD for $824.00. Do it for a lot of desks and you should be able to do better on price - those prices are retail, onesies, direct from Apple. You get gigabit ethernet (and 10/100, of course), 4 USB 2.0 ports, a firewire 400 port, DVI/VGA monitor port, audio in and out, 1.66 GHz core speed, 24x CD/CDRW/DVD drive, and the current OSX, which includes Address Book, DVD Player, iCal, iChat AV, Mail, Preview, Web browser and even the software development system. You can slap Openoffice on there with zero trouble and zero cost, and you've got your basic corporate desktop, with a strong *nix underpinning for your power-users and an ultra-friendly, ultra-reliable GUI for everyone else.
That initial cost is in the same zone, and you get one hell of a lot better computer, operating system, hugely lessened support load, tiny desktop footprint, still have the ability to concurrently run Windows (Parallels is the way to go, but it is a few extra bucks) with OSX... I put minis all over my software company and I haven't had any cause to regret it. We don't have a single desktop that runs a PC today, nor do I anticipate we ever will again.
Also, I bet you don't "control what [you]'re linked with to a very fine degree" on Windows - your application is almost certainly linked to many system libraries over which you have absolutely no control whatsover.
You'd lose your bet right out of the gate. We use the absolute minimum of system calls, and we develop under a very early version of Visual Studio using an old-school makefile that directly controls what we link with. We use C, not C++, and consequently, there are no hidden dependencies. Further, our code is broken into sections that have no external references at all, and sections that encapsulate the particular OS paradigm that it has to run with for any one version, making it quite trivial (as well as a requirement) to control what OS resources are utilized. That's also why our flagship app has considerably more functionality than anything else in its class while the total executable (including our DLLs) remains a fraction of the size of the competing applications. But I understand why you'd think the way you do; modern application development is a bloated, sluggish mess. A lot of people and companies bought the C++ bait hook, line and sinker, and consequently, application bloat and dependency sprawl are the rule, rather than the exception.
Not to rub salt in the wound, but my Macbook Pro boots in about 20 seconds from power on to "do anything you want" unless it's just had a software upgrade and has to prod the hardware on the way to restarting. Something to consider, anyway.
With Microsoft, they're about sales. So they're going to do whatever they can to get sales.
Well then, they shouldn't have DRM'd their operating system with "activation"; they shouldn't have broken all those applications; they shouldn't have bought into consumer-unfriendly technologies, particularly in the area of media but also in hardware; they shouldn't have forbidden any of Vista's versions to run under virtualization; they shouldn't have made using Vista a nightmare of clicking away security popups; they shouldn't have insisted on proprietary, insecure solutions like ActiveX; they definitely shouldn't charge for development tools; and of course, the predatory business practices don't make them any friends, either.
Me, I jumped ship and I'm not looking back. XP's activation DRM was the last straw.
I'm not offended in the least. We have our reasons, and I am satisfied that they are sufficient. I was simply attempting to explain them. The bottom line is, dynamic linking isn't acceptable; and static is impossible because of the license terms.
The general thinking - which may not be correct - is that the armed forces will not be generally willing to fire on US citizens in revolt. Should such a revolt occur, certainly the reasons would be well known; one assumes that a few soldiers, marines, etc would be minded to join the cause, whatever it was characterized as being at that point.
Another somewhat pointed observation is that US forces are all over Iraq at this point, and they are taking a hell of a beating from a populace armed only with makeshift explosives, handguns and rifles. It would be worse here, probably a lot worse.
So the presumption that the army can overcome by force of arms may be optimistic.
You have not offended me in the least, despite your continuing use of terms like "douche"; that kind of behavior just makes you look bad. I am only interested in discussing the subject at hand. With regard to that, you have failed to make any reasonable presentation of your position. Your skin is far too thin to be debating substantive issues, as near as I can figure out. It seems to me that you are one of those people that when backed into a corner by the facts or an argument you cannot refute, resorts to name calling in an attempt to distract those following the discourse from your failure. Perhaps you should work on that. In the meantime, my points stand.
Let me ask you this: WHY do you feel it is wrong that they have to get a permit, besides the fact that it's in the constitution? Because if that's the only reason you have then -no offense intended- that sounds like dogma to me.
OK, several things. First, I have no particular objection to permits in principle; for the very reasons you mention, and a few others like them. However, the constitution is the only line of authority that exists for my government; in order for them to be operating legitimately, everything they do must comply with that document. So, if they want to say (for instance) that assembly requires a permit, but permits must be issued on request within so many hours or days, then they must amend (change) the constitution so that they have the authority to make such a law. There is a procedure for them to make such changes, they aren't by any means locked into the current state of affairs. Now, you observe that this is a small matter, and (in the case of the loonies in the KKK) it may well be, but in the case of a serious grievance needing to be presented to the government, it isn't a small matter, and the reason that the constitution guarantees freedom of assembly is specifically so that the government cannot undermine that situation. There's another problem. Let's say that it is entirely reasonable, whatever change they want to make. Regardless of what it is, lets just agree up front that it is 100% benign. Still, if we allow laws that do not follow the constitution in one area, where is the justification for us to say "no" in another area, such as restricting free speech, or removing the right to a jury trial? This is why they must make the changes according to the correct procedure before they can make such a law. That way, they will be in compliance. The procedure itself can be found here, under "Amendment."
The bottom line is, the government must act within its legitimate authority. If it does not, then it is telling citizens what to do without any authority, and all that is left at that point is coercion, that is, force or the threat of force. The founders of our nation were well experienced with coercive government, and the constitution was their attempt to see to it that the rest of us would not have to experience such a thing. It would work out, too, if our government would stick to the constitution, but as George W Bush says, "it's just a goddamned piece of paper" and at this point in time, it plays only a shadow of the role that it was intended to. This is a crisis that most of the country is unaware of because they aren't even familiar with the constitution, much less have an understanding of how it is supposed to authorize governmental authority.
With the LGPL, we can't use static linking, because if we do, the license we release our proprietary code under must allow for reverse engineering to remove the LGPL'd library at a later date. Dynamic linking means that the installation can be broken too easily — if we can't control what we're linked with to a very fine degree, we can't release the product. So GTK is unusable for us. It just isn't designed to integrate reasonably with a proprietary application, which is fine as far as it goes — they have every right to lay down such conditions — but does stop us cold.
Here is the relevant LGPL clause, emphasis mine:
6. As an exception to the Sections above, you may also combine or
link a "work that uses the Library" with the Library to produce a
work containing portions of the Library, and distribute that work
under terms of your choice, provided that the terms permit
modification of the work for the customer's own use and reverse
engineering for debugging such modifications.
See the problem? With static linking, we can ensure that the widgets and so forth in use are the ones we need and the ones we tested with. But we can't do that because of the LGPL's reverse engineering clause. With dynamic linking, anyone - literally anyone, since the library is open source - can fool with it to any degree, causing anything from crashes to destabilization to adding outright malware. Or they could simply change the library with the best of intentions and break us hard anyway. We just can't release an application under those conditions; it compounds liability, support and usability issues, and on something we want to give away, and so will have no income stream to cover such issues.
This is why I recommend that if people really want to make their software useful to the widest possible set of users, they stay away from the LGPL and even more so, the GPL. OTOH, If you want your code to be restricted, then by all means, of course, go with one of these licenses. Personally, the things I write that I want other people to use, I just release PD. Then anyone can use them without worrying about what my opinion might be. I've got a tiny SQL-like database engine with some very cool features, written in Python and currently only 20k in size. I've got about 90% done (it works fine, just doesn't have indexing yet) and it'll be PD when the time comes. To me, free means really free, rather than enforcing my idea of what you should do. But that's just me. Anyway, that's what we're looking for, too. We just need widgets; we don't need legal pitfalls and we certainly aren't interested in opening our application up for reverse engineering.
Not in the sense of constitutionally, they didn't - there is no authority to curtail the freedom to assemble that derives from the constitution; it is explicitly forbidden to the fed, and to the states.
I realize perfectly well that both the fed and the state have made unconstitutional laws that use coercion to illegitimately take this right from the citizens. But these are illegal laws. Here's the 1st amendment:
Congress shall make no law respecting an establishment of religion, or prohibiting the free exercise thereof; or abridging the freedom of speech, or of the press; or the right of the people peaceably to assemble, and to petition the Government for a redress of grievances.
The constitution, of course, applies to the feds, mainly. However, amendments 1 through 10 (the bill of rights) is applied 100% to the states by the 14th amendment. So that means that the above 100% applies to Texas; shall make no law. Perfectly clear. Now, this can be changed by a specific procedure that amends the constitution. That hasn't been done for assembly, with or without petitioning, and it hasn't been done for any of the rest of the 1st either, so there is literally no legitimate law that restricts any of these rights. It can't be legitimate, because the only authority available is the constitution, and when they don't have that, they don't have anything.
For weeks beforehand, there was debate over whether the city was right to grant a permit for the rally to the KKK.
Let me solve that for you. They weren't right. Because the KKK do not need a permit to assemble under any circumstances. Freedom of assembly is guaranteed at the federal level by the 1st amendment; the 14th amendment says that Texas (and every other state) has to obey the first amendment and all the other amendments as well.
Of course, "right" has nothing to do with government these days. "Corrupt" and "coercive" are the words that are most apt.
Haven't they learned from their post-Nazi policies that have produced nothing but xenophobia and racism in their countries?
No. And they aren't going to, either. Neither have we, as is amply demonstrated by the current highly eroded state of the bill of rights, as well as other parts of the constitution. Any other questions?
The Bill of Rights are not subject to withdrawl, they are Rights, not priviledges.
Sadly, the bill of rights, as well as large sections elsewhere in the constitution, have been withdrawn in terms of having the force of law. There was no authority given to do so, but nonetheless, it is done and over with. The only amendment that remains untrampled is #3.
US of A: Hate speech is curtailed through auto-censorship (commercial censorship)
Well... not really. In the US, first the government created artificial scarcity by denying the people access to the airwaves unless they were rich, in which case they were sold the right to broadcast for many miles. Then we applied direct censorship and religious preference to the resource, via the FCC. "Obscenity" and other religious impositions, you see. Since it is the government that artificially made radio a commercial enterprise, you can still lay the blame for "commercial" censorship, as you call it, at their feet.
Without the government, anyone could have access to the airwaves. There's nothing magical or technically difficult about running a radio station. Takes about $50 worth of parts to reach all over a small town, and there are many available channels and bands upon which we could do so. But that's all a pipe dream. We're not allowed to have anything like that. That would require... a free country. Nothing like that around here.
Many of us Europeans prefer some legal tools to stop the idiots.
Oh, us American types do, too. Our tool to stop the idiots is called the "1st amendment." It just isn't working very well right now. Free speech zones, radio and television censorship, permits required to assemble, that sort of thing. We've got some legislators and judges that can't read plain English, and that tends to break things.
Dude, your web site has a ton of broken links, because I have 2 levels of web cache on my browser. Did you ever think about that when coming up with the "clever" idea of moving all the pages around from time to time?
So clear your cache. We move the pages around because it breaks most deep mining, which we have a significant problem with. Stolen bandwidth is bandwidth you don't get to use, as someone who, for whatever reason, is actually looking at our site. Also, stolen bandwidth costs money, money I assume you're not willing to pay. Right? Because if you are, let me give you an address for you to send the checks to, OK?
Oh, and I see no evidence of any OS X products on the pages I can get to...
Nope, none yet. We're working on it. Won't be anything until well after the release of Leopard. You can run the current applications under Parallels or Bootcamp, if you need functionality we offer that you can't duplicate elsewhere and you have an Intel machine. There will be an upgrade path provided that 100% accounts for anything you spend.
Hmm, I am not sure I would use any, non-strategic, software product again unless it was completely, openly GPLd, and could potentially live forever.
There's no particular reason to presume that WinImages will stop working, unless MS drops compatibility with its basic OS resources - there's no sign of that. And of course you can always run old versions of windows, sandboxed. In fact, that's pretty much the only way I run Windows these days, snuggled inside Parallels, networking turned off, happily inside an OSX window.
I see WinImages only supports through XP - you say Vista won't happen?
We're not going to make any changes for Vista; that's not to say that it won't work there. If Vista gets weird to the point where WinImages won't work, so will most everything else. We hardly use any system calls at all compared to most applications, the ones we do use are really basic (memory allocation... dialogs... widgets... windows.... menus... mouse... fread / fwrite / fopen / fclose) and the only DLLs we really depend upon are MS's own Visual Studio DLLs that define the system interface (which again, aren't about to go away) and DLLs that we supply that are entirely under our own control. Having said all that, we've done absolutely zero testing in/for Vista on the one hand, and on the other, we've had zero problem reports for Vista, and it's been quite some time now. So I think it's pretty safe to say that for the same reasons WinImages worked without changes through 98, NT, Me, 2000, and XP... it'll work with Vista, too. But no - I won't promise that, and we aren't advertising that. I keep meaning to run downtown and pester the local computer guy who has Vista running and run a basic test install, but you know, I really don't care that much. Vista is like XP; it is DRM'd out of the box with "activation" and I just think it isn't worthy of support.
What has happened to your past Amiga customers, now Windows.
Our Amiga customers were left with fully functional programs that worked 100% on the very latest OS Commodore shipped with the machines; we ran on every one from the lowliest 500 or A1000 to the last gasp towers. The Amiga market then completely lost coherence with CBM's demise, and has only gotten worse to this day. Nothing we can do about it. Windows is another ball of wax entirely. Activation DRM is everyone's concern, and as things stand today, we're not encouraging anyone to buy Vista because it is no better than XP in that regard.
When wither OS/X?
I can't answer that. I don't like to make promises we may not be able to keep. A couple of things, though; it isn't a port. It's a 64-bit app, brand new from the ground up, including new UI ideas. WinImages is the source for the technology, sure enough, but no code is being moved. So it'll be a while. You'll have lots of time to get used to Leopard, of that I can assure you. Once it is done and we're comfortable with the stability, we'll consider porting back to Windows. But that isn't a promise that we will do so. Right now, Windows kind of sucks. Microsoft has some things to do yet if we are to continue supporting new versions of the platform. And my feeling is that Microsoft doesn't really give a flying fig. However, my impression is also that most of he world doesn't give a flying fig about Vista, for a wonder.
Your software still looks like a 16-bit Windows application. I imagine the code isn't very portable to begin with. Hence your difficulty in porting.
We use the most basic GUI API possible as a matter of policy. That is why you see the low color icons and so forth. It isn't an accident, or the result of "old code". Though it is a policy we've been following since 1985, when we released our first GUI program, PCLO, a printed circuit board layout CAD system.
However, your speculation on "difficulty in porting" is entirely off the mark. Our stuff is easy to port because the amount of dependencies on the OS, including GUI requirements, is minimal. The applications themselves are straight C code through and through. Our main apps were ported to Windows from the Amiga, a completely different system with a completely different GUI layer, in about two days. The application controls and signal catching are highly modular internally, and we have no problem whatsoever porting them. They were never "spaghettied" through the code, so it is not all that much work to replace them wholesale. The only potentially daunting task is bitmap conversion; there are hundreds of icon bitmaps buried inside Visual Studio, and getting them out is annoying to the tune of several hours of make-work.
Further, that same minimalist approach has meant that our software continues to work without changes on each successive release of Windows, and it also allowed us to port to the PowerPC, Alpha and MIPS versions of windows in very short order. Maintaining the RISC versions was a bit of a bitch because Microsoft kept doing things like invert the Y axis on font rotation and just generally foul up their RISC code. Our linux port was done in less than a week (and some of that was just fooling with different widget sets.) You presume we had "difficulty in porting", but that isn't what I said. I said we weren't going to release a port.
With regard to Windows, the same version still runs on 95, 98, NT, 2000, Me, XP and Vista. All releases and all service pack levels for all versions. The same system calls. The same code. It has to be recompiled for RISC targets, but that's only a minor problem; there's no difference in the GUI layer there, either. The lack of RISC machines is the real problem. Microsoft really screwed those people hard. But that's a different discussion.
The code for the application core is 32-bit and always has been (the Amiga offering / demanding a flat memory model long before Windows ever went there.) But even so, the current release version is anything but "16-bit." We're currently working on a 64-bit version that is broadly multiple CPU/core aware, and that is going to finally break our long chain of compatibility. I have to admit, way back in the 80's, 32-bit did seem like enough. Not that the tools really would have let us build a 64-bit app at the time. Still, although 32-bits is enough for a lot of things, 64-bit does some really nice things for deep pixel manipulation, and the new stuff is fun to fool with. We're still using the minimum calls to the OS, though. You never know what is around the corner.
GTK is your GUI target. If you need a C++-based library, then target wxWindows or QT
GTK is LGPL. So we can't use it. wxWindows uses GTK, which is LGPL, so we can't use it. QT is costly for a proprietary application, and again, that's not going to fly with a free product.
The original poster said he wanted to port his application to Linux. And the correct response to that is: Linux is just a kernel.
I'm the original poster. What I said was "the only reason we've not released a port to linux", which is something else entirely. Our key apps have been ported already (which is why I even know about these issues); I have a perfectly functional copy installed under RH9, which in turn is sandboxed on my Mac. But the licensing for the widget set is unacceptable for release, and therefore, we aren't going to release it. Get a standard GUI layer that all desk/lap/tablet-top distributions carry (just as they do xwindows), unencumbered by licensing terms that in any way require that we release our IP to the community, free, and I'd be able to authorize release of a port that won't step on anyone's toes, incur any hidden liabilities, or cost anyone any more money. Obviously, we've spent a lot of money on our application development, but I consider that a fair trade for years of use of apache and perl and python and so forth.
To very quickly address your "kernel" argument: please tell me which distributions of desktop, laptop, and/or tablet versions of the linux kernel come without - for instance - a shell, "rm" and "ls", to name just a few components? None? Why, what a surprise. Now, let's step it up a notch, and turn it around. Which GUI applications, using any widget set you care to name or simply xwindows, like "xnetload", are targeted at a distribution that comes without a kernel? None? Why, again, what a surprise. So apparently, if you call the general set of distributions "linux", which means "kernel" to you, the user still gets everything, assuming only you're not developing a black box of some type. So naturally, when people say "linux", they mean the same thing as they do when they say "OSX" or "Windows." So let's not quibble about terminology. You know what I meant when I said that I wanted a standard GUI layer. I simply want to be able to be certain that all the distributions that are aimed at platforms like desktops, laptops, and tablets carry that functionality, so that when the software calls a system function, it is going to be there, each and every time, there will be no licensing issues, there will be no compatibility / version issues, there will be no additional expense, and there won't be a flock of technical support incidents explaining why the software won't run on distribution XYZ.
I've got apps written for Windows95 that still work just as they were designed to today, across every Windows OS except the non-Intel versions. The same GUI calls that worked back then still work today, just a lot faster. That's what I am suggesting linux distributions need. A basic set of stable, uniform GUI calls. That's all. It isn't magic, and it isn't unreasonable. And of course, it doesn't have to happen. It's just what I think the OS needs to be taken seriously by a large number of developers who don't do so now. I'd like it if it were; I'm a fan of the OS and to some extent, the mindset behind developing for each other (my enthusiasm disappears as soon as someone mentions the word "license.") As far as I am concerned, the words "free" and "license" are about as compatible as are human physiology and the Ebola virus.
Oh, it's helpful, all right. For instance, the only reason we've not released a port to linux - a free version, of course, we'd like to give back to the community - is because there is no standard GUI layer. It's a hodgepodge of these widgets and those widgets, this license and that license (really meaning, these liabilities and those liabilities.) Windows provides all that. Free. Built in. Plus a large market. So we developed for them. When Windows became intolerable because of activation DRM, we moved to OSX. Nice GUI layer, free, built-in. development proceeds apace, while linux runs servers. Others may have other reasons, but those are ours. The day the linux core gets BUILT-IN windowing and graphics, and I do NOT mean just xwindows or xwindows plus yet another sometimes-there and restrictively licensed widget set, is the day we make a port that we will release to the community. The community can then, of course, use our stuff or not as they see fit - but as is, it's not a choice. That's been the unanimous decision of the linux community: no coherence.
I want to say one more thing. The existence of a standard GUI layer in NO way means that you can't still have everything you have now. You'd just have one more thing, something people could write to as a default, even just as a fall-back.
Legality is not the same as morality/ethics. Some people are more concerned about the morality of their actions than the legality of their actions. I, for example, care very little about the legality of my actions. However, I am concerned with the likely consequences of my actions, and that means I must consider whether I am likely to be punished is some way for actions I am considering. This is often related to the legality of those actions, but again it is not the legality which concerns me -- only the ethical considerations paired with whether and to what extent I am likely to be punished. Sometimes, those two sets of concerns are even at odds with each other, unfortunately.
I just want to say that I was delighted to read such a clearheaded and inherently correct paragraph. My hat is off to you, sir.
Slashdot Mirror
FORD: "Found On Road, Dead"
FORD: "Fix Or Repair Daily"
FORD: "Frequently Overhauled, Rarely Driven"
Keep the current keyboard, mouse and monitor, replace the PC with a 1 gig RAM/80 GB HD dual-core mini, and you're "Mac-ified" for $724.00. You can go to 120 GB HD for $824.00. Do it for a lot of desks and you should be able to do better on price - those prices are retail, onesies, direct from Apple. You get gigabit ethernet (and 10/100, of course), 4 USB 2.0 ports, a firewire 400 port, DVI/VGA monitor port, audio in and out, 1.66 GHz core speed, 24x CD/CDRW/DVD drive, and the current OSX, which includes Address Book, DVD Player, iCal, iChat AV, Mail, Preview, Web browser and even the software development system. You can slap Openoffice on there with zero trouble and zero cost, and you've got your basic corporate desktop, with a strong *nix underpinning for your power-users and an ultra-friendly, ultra-reliable GUI for everyone else.
That initial cost is in the same zone, and you get one hell of a lot better computer, operating system, hugely lessened support load, tiny desktop footprint, still have the ability to concurrently run Windows (Parallels is the way to go, but it is a few extra bucks) with OSX... I put minis all over my software company and I haven't had any cause to regret it. We don't have a single desktop that runs a PC today, nor do I anticipate we ever will again.
You'd lose your bet right out of the gate. We use the absolute minimum of system calls, and we develop under a very early version of Visual Studio using an old-school makefile that directly controls what we link with. We use C, not C++, and consequently, there are no hidden dependencies. Further, our code is broken into sections that have no external references at all, and sections that encapsulate the particular OS paradigm that it has to run with for any one version, making it quite trivial (as well as a requirement) to control what OS resources are utilized. That's also why our flagship app has considerably more functionality than anything else in its class while the total executable (including our DLLs) remains a fraction of the size of the competing applications. But I understand why you'd think the way you do; modern application development is a bloated, sluggish mess. A lot of people and companies bought the C++ bait hook, line and sinker, and consequently, application bloat and dependency sprawl are the rule, rather than the exception.
Not to rub salt in the wound, but my Macbook Pro boots in about 20 seconds from power on to "do anything you want" unless it's just had a software upgrade and has to prod the hardware on the way to restarting. Something to consider, anyway.
Well then, they shouldn't have DRM'd their operating system with "activation"; they shouldn't have broken all those applications; they shouldn't have bought into consumer-unfriendly technologies, particularly in the area of media but also in hardware; they shouldn't have forbidden any of Vista's versions to run under virtualization; they shouldn't have made using Vista a nightmare of clicking away security popups; they shouldn't have insisted on proprietary, insecure solutions like ActiveX; they definitely shouldn't charge for development tools; and of course, the predatory business practices don't make them any friends, either.
Me, I jumped ship and I'm not looking back. XP's activation DRM was the last straw.
Understood.
I'm not offended in the least. We have our reasons, and I am satisfied that they are sufficient. I was simply attempting to explain them. The bottom line is, dynamic linking isn't acceptable; and static is impossible because of the license terms.
The general thinking - which may not be correct - is that the armed forces will not be generally willing to fire on US citizens in revolt. Should such a revolt occur, certainly the reasons would be well known; one assumes that a few soldiers, marines, etc would be minded to join the cause, whatever it was characterized as being at that point.
Another somewhat pointed observation is that US forces are all over Iraq at this point, and they are taking a hell of a beating from a populace armed only with makeshift explosives, handguns and rifles. It would be worse here, probably a lot worse.
So the presumption that the army can overcome by force of arms may be optimistic.
You have not offended me in the least, despite your continuing use of terms like "douche"; that kind of behavior just makes you look bad. I am only interested in discussing the subject at hand. With regard to that, you have failed to make any reasonable presentation of your position. Your skin is far too thin to be debating substantive issues, as near as I can figure out. It seems to me that you are one of those people that when backed into a corner by the facts or an argument you cannot refute, resorts to name calling in an attempt to distract those following the discourse from your failure. Perhaps you should work on that. In the meantime, my points stand.
OK, several things. First, I have no particular objection to permits in principle; for the very reasons you mention, and a few others like them. However, the constitution is the only line of authority that exists for my government; in order for them to be operating legitimately, everything they do must comply with that document. So, if they want to say (for instance) that assembly requires a permit, but permits must be issued on request within so many hours or days, then they must amend (change) the constitution so that they have the authority to make such a law. There is a procedure for them to make such changes, they aren't by any means locked into the current state of affairs. Now, you observe that this is a small matter, and (in the case of the loonies in the KKK) it may well be, but in the case of a serious grievance needing to be presented to the government, it isn't a small matter, and the reason that the constitution guarantees freedom of assembly is specifically so that the government cannot undermine that situation. There's another problem. Let's say that it is entirely reasonable, whatever change they want to make. Regardless of what it is, lets just agree up front that it is 100% benign. Still, if we allow laws that do not follow the constitution in one area, where is the justification for us to say "no" in another area, such as restricting free speech, or removing the right to a jury trial? This is why they must make the changes according to the correct procedure before they can make such a law. That way, they will be in compliance. The procedure itself can be found here, under "Amendment."
The bottom line is, the government must act within its legitimate authority. If it does not, then it is telling citizens what to do without any authority, and all that is left at that point is coercion, that is, force or the threat of force. The founders of our nation were well experienced with coercive government, and the constitution was their attempt to see to it that the rest of us would not have to experience such a thing. It would work out, too, if our government would stick to the constitution, but as George W Bush says, "it's just a goddamned piece of paper" and at this point in time, it plays only a shadow of the role that it was intended to. This is a crisis that most of the country is unaware of because they aren't even familiar with the constitution, much less have an understanding of how it is supposed to authorize governmental authority.
With the LGPL, we can't use static linking, because if we do, the license we release our proprietary code under must allow for reverse engineering to remove the LGPL'd library at a later date. Dynamic linking means that the installation can be broken too easily — if we can't control what we're linked with to a very fine degree, we can't release the product. So GTK is unusable for us. It just isn't designed to integrate reasonably with a proprietary application, which is fine as far as it goes — they have every right to lay down such conditions — but does stop us cold.
Here is the relevant LGPL clause, emphasis mine:
See the problem? With static linking, we can ensure that the widgets and so forth in use are the ones we need and the ones we tested with. But we can't do that because of the LGPL's reverse engineering clause. With dynamic linking, anyone - literally anyone, since the library is open source - can fool with it to any degree, causing anything from crashes to destabilization to adding outright malware. Or they could simply change the library with the best of intentions and break us hard anyway. We just can't release an application under those conditions; it compounds liability, support and usability issues, and on something we want to give away, and so will have no income stream to cover such issues.
This is why I recommend that if people really want to make their software useful to the widest possible set of users, they stay away from the LGPL and even more so, the GPL. OTOH, If you want your code to be restricted, then by all means, of course, go with one of these licenses. Personally, the things I write that I want other people to use, I just release PD. Then anyone can use them without worrying about what my opinion might be. I've got a tiny SQL-like database engine with some very cool features, written in Python and currently only 20k in size. I've got about 90% done (it works fine, just doesn't have indexing yet) and it'll be PD when the time comes. To me, free means really free, rather than enforcing my idea of what you should do. But that's just me. Anyway, that's what we're looking for, too. We just need widgets; we don't need legal pitfalls and we certainly aren't interested in opening our application up for reverse engineering.
Not in the sense of constitutionally, they didn't - there is no authority to curtail the freedom to assemble that derives from the constitution; it is explicitly forbidden to the fed, and to the states.
I realize perfectly well that both the fed and the state have made unconstitutional laws that use coercion to illegitimately take this right from the citizens. But these are illegal laws. Here's the 1st amendment:
The constitution, of course, applies to the feds, mainly. However, amendments 1 through 10 (the bill of rights) is applied 100% to the states by the 14th amendment. So that means that the above 100% applies to Texas; shall make no law. Perfectly clear. Now, this can be changed by a specific procedure that amends the constitution. That hasn't been done for assembly, with or without petitioning, and it hasn't been done for any of the rest of the 1st either, so there is literally no legitimate law that restricts any of these rights. It can't be legitimate, because the only authority available is the constitution, and when they don't have that, they don't have anything.
Let me solve that for you. They weren't right. Because the KKK do not need a permit to assemble under any circumstances. Freedom of assembly is guaranteed at the federal level by the 1st amendment; the 14th amendment says that Texas (and every other state) has to obey the first amendment and all the other amendments as well.
Of course, "right" has nothing to do with government these days. "Corrupt" and "coercive" are the words that are most apt.
No. And they aren't going to, either. Neither have we, as is amply demonstrated by the current highly eroded state of the bill of rights, as well as other parts of the constitution. Any other questions?
Sadly, the bill of rights, as well as large sections elsewhere in the constitution, have been withdrawn in terms of having the force of law. There was no authority given to do so, but nonetheless, it is done and over with. The only amendment that remains untrampled is #3.
Well... not really. In the US, first the government created artificial scarcity by denying the people access to the airwaves unless they were rich, in which case they were sold the right to broadcast for many miles. Then we applied direct censorship and religious preference to the resource, via the FCC. "Obscenity" and other religious impositions, you see. Since it is the government that artificially made radio a commercial enterprise, you can still lay the blame for "commercial" censorship, as you call it, at their feet.
Without the government, anyone could have access to the airwaves. There's nothing magical or technically difficult about running a radio station. Takes about $50 worth of parts to reach all over a small town, and there are many available channels and bands upon which we could do so. But that's all a pipe dream. We're not allowed to have anything like that. That would require... a free country. Nothing like that around here.
Oh, us American types do, too. Our tool to stop the idiots is called the "1st amendment." It just isn't working very well right now. Free speech zones, radio and television censorship, permits required to assemble, that sort of thing. We've got some legislators and judges that can't read plain English, and that tends to break things.
I'd just like to say that I HATE the EU for doing this.
So clear your cache. We move the pages around because it breaks most deep mining, which we have a significant problem with. Stolen bandwidth is bandwidth you don't get to use, as someone who, for whatever reason, is actually looking at our site. Also, stolen bandwidth costs money, money I assume you're not willing to pay. Right? Because if you are, let me give you an address for you to send the checks to, OK?
Nope, none yet. We're working on it. Won't be anything until well after the release of Leopard. You can run the current applications under Parallels or Bootcamp, if you need functionality we offer that you can't duplicate elsewhere and you have an Intel machine. There will be an upgrade path provided that 100% accounts for anything you spend.
There's no particular reason to presume that WinImages will stop working, unless MS drops compatibility with its basic OS resources - there's no sign of that. And of course you can always run old versions of windows, sandboxed. In fact, that's pretty much the only way I run Windows these days, snuggled inside Parallels, networking turned off, happily inside an OSX window.
We're not going to make any changes for Vista; that's not to say that it won't work there. If Vista gets weird to the point where WinImages won't work, so will most everything else. We hardly use any system calls at all compared to most applications, the ones we do use are really basic (memory allocation... dialogs... widgets... windows.... menus... mouse... fread / fwrite / fopen / fclose) and the only DLLs we really depend upon are MS's own Visual Studio DLLs that define the system interface (which again, aren't about to go away) and DLLs that we supply that are entirely under our own control. Having said all that, we've done absolutely zero testing in/for Vista on the one hand, and on the other, we've had zero problem reports for Vista, and it's been quite some time now. So I think it's pretty safe to say that for the same reasons WinImages worked without changes through 98, NT, Me, 2000, and XP... it'll work with Vista, too. But no - I won't promise that, and we aren't advertising that. I keep meaning to run downtown and pester the local computer guy who has Vista running and run a basic test install, but you know, I really don't care that much. Vista is like XP; it is DRM'd out of the box with "activation" and I just think it isn't worthy of support.
Our Amiga customers were left with fully functional programs that worked 100% on the very latest OS Commodore shipped with the machines; we ran on every one from the lowliest 500 or A1000 to the last gasp towers. The Amiga market then completely lost coherence with CBM's demise, and has only gotten worse to this day. Nothing we can do about it. Windows is another ball of wax entirely. Activation DRM is everyone's concern, and as things stand today, we're not encouraging anyone to buy Vista because it is no better than XP in that regard.
I can't answer that. I don't like to make promises we may not be able to keep. A couple of things, though; it isn't a port. It's a 64-bit app, brand new from the ground up, including new UI ideas. WinImages is the source for the technology, sure enough, but no code is being moved. So it'll be a while. You'll have lots of time to get used to Leopard, of that I can assure you. Once it is done and we're comfortable with the stability, we'll consider porting back to Windows. But that isn't a promise that we will do so. Right now, Windows kind of sucks. Microsoft has some things to do yet if we are to continue supporting new versions of the platform. And my feeling is that Microsoft doesn't really give a flying fig. However, my impression is also that most of he world doesn't give a flying fig about Vista, for a wonder.
We use the most basic GUI API possible as a matter of policy. That is why you see the low color icons and so forth. It isn't an accident, or the result of "old code". Though it is a policy we've been following since 1985, when we released our first GUI program, PCLO, a printed circuit board layout CAD system.
However, your speculation on "difficulty in porting" is entirely off the mark. Our stuff is easy to port because the amount of dependencies on the OS, including GUI requirements, is minimal. The applications themselves are straight C code through and through. Our main apps were ported to Windows from the Amiga, a completely different system with a completely different GUI layer, in about two days. The application controls and signal catching are highly modular internally, and we have no problem whatsoever porting them. They were never "spaghettied" through the code, so it is not all that much work to replace them wholesale. The only potentially daunting task is bitmap conversion; there are hundreds of icon bitmaps buried inside Visual Studio, and getting them out is annoying to the tune of several hours of make-work.
Further, that same minimalist approach has meant that our software continues to work without changes on each successive release of Windows, and it also allowed us to port to the PowerPC, Alpha and MIPS versions of windows in very short order. Maintaining the RISC versions was a bit of a bitch because Microsoft kept doing things like invert the Y axis on font rotation and just generally foul up their RISC code. Our linux port was done in less than a week (and some of that was just fooling with different widget sets.) You presume we had "difficulty in porting", but that isn't what I said. I said we weren't going to release a port.
With regard to Windows, the same version still runs on 95, 98, NT, 2000, Me, XP and Vista. All releases and all service pack levels for all versions. The same system calls. The same code. It has to be recompiled for RISC targets, but that's only a minor problem; there's no difference in the GUI layer there, either. The lack of RISC machines is the real problem. Microsoft really screwed those people hard. But that's a different discussion.
The code for the application core is 32-bit and always has been (the Amiga offering / demanding a flat memory model long before Windows ever went there.) But even so, the current release version is anything but "16-bit." We're currently working on a 64-bit version that is broadly multiple CPU/core aware, and that is going to finally break our long chain of compatibility. I have to admit, way back in the 80's, 32-bit did seem like enough. Not that the tools really would have let us build a 64-bit app at the time. Still, although 32-bits is enough for a lot of things, 64-bit does some really nice things for deep pixel manipulation, and the new stuff is fun to fool with. We're still using the minimum calls to the OS, though. You never know what is around the corner.
GTK is LGPL. So we can't use it. wxWindows uses GTK, which is LGPL, so we can't use it. QT is costly for a proprietary application, and again, that's not going to fly with a free product.
Yes. I know. That's the whole point.
I'm the original poster. What I said was "the only reason we've not released a port to linux", which is something else entirely. Our key apps have been ported already (which is why I even know about these issues); I have a perfectly functional copy installed under RH9, which in turn is sandboxed on my Mac. But the licensing for the widget set is unacceptable for release, and therefore, we aren't going to release it. Get a standard GUI layer that all desk/lap/tablet-top distributions carry (just as they do xwindows), unencumbered by licensing terms that in any way require that we release our IP to the community, free, and I'd be able to authorize release of a port that won't step on anyone's toes, incur any hidden liabilities, or cost anyone any more money. Obviously, we've spent a lot of money on our application development, but I consider that a fair trade for years of use of apache and perl and python and so forth.
To very quickly address your "kernel" argument: please tell me which distributions of desktop, laptop, and/or tablet versions of the linux kernel come without - for instance - a shell, "rm" and "ls", to name just a few components? None? Why, what a surprise. Now, let's step it up a notch, and turn it around. Which GUI applications, using any widget set you care to name or simply xwindows, like "xnetload", are targeted at a distribution that comes without a kernel? None? Why, again, what a surprise. So apparently, if you call the general set of distributions "linux", which means "kernel" to you, the user still gets everything, assuming only you're not developing a black box of some type. So naturally, when people say "linux", they mean the same thing as they do when they say "OSX" or "Windows." So let's not quibble about terminology. You know what I meant when I said that I wanted a standard GUI layer. I simply want to be able to be certain that all the distributions that are aimed at platforms like desktops, laptops, and tablets carry that functionality, so that when the software calls a system function, it is going to be there, each and every time, there will be no licensing issues, there will be no compatibility / version issues, there will be no additional expense, and there won't be a flock of technical support incidents explaining why the software won't run on distribution XYZ.
I've got apps written for Windows95 that still work just as they were designed to today, across every Windows OS except the non-Intel versions. The same GUI calls that worked back then still work today, just a lot faster. That's what I am suggesting linux distributions need. A basic set of stable, uniform GUI calls. That's all. It isn't magic, and it isn't unreasonable. And of course, it doesn't have to happen. It's just what I think the OS needs to be taken seriously by a large number of developers who don't do so now. I'd like it if it were; I'm a fan of the OS and to some extent, the mindset behind developing for each other (my enthusiasm disappears as soon as someone mentions the word "license.") As far as I am concerned, the words "free" and "license" are about as compatible as are human physiology and the Ebola virus.
Oh, it's helpful, all right. For instance, the only reason we've not released a port to linux - a free version, of course, we'd like to give back to the community - is because there is no standard GUI layer. It's a hodgepodge of these widgets and those widgets, this license and that license (really meaning, these liabilities and those liabilities.) Windows provides all that. Free. Built in. Plus a large market. So we developed for them. When Windows became intolerable because of activation DRM, we moved to OSX. Nice GUI layer, free, built-in. development proceeds apace, while linux runs servers. Others may have other reasons, but those are ours. The day the linux core gets BUILT-IN windowing and graphics, and I do NOT mean just xwindows or xwindows plus yet another sometimes-there and restrictively licensed widget set, is the day we make a port that we will release to the community. The community can then, of course, use our stuff or not as they see fit - but as is, it's not a choice. That's been the unanimous decision of the linux community: no coherence.
I want to say one more thing. The existence of a standard GUI layer in NO way means that you can't still have everything you have now. You'd just have one more thing, something people could write to as a default, even just as a fall-back.
That's my 2 cents.
I just want to say that I was delighted to read such a clearheaded and inherently correct paragraph. My hat is off to you, sir.
Here you go. Now fix it.