Have there been any attempts to pass a serious budget in the senate regardless of what the Republicans are doing? I have heard of budgets being brought forward that neither party was going to support which I would call political versus a serious budget.
For what they have done, I think it is a good thing since it looks like a lot of the changes are bug fixes where language would not matter.
From the description of Lotus Symphony ( https://en.wikipedia.org/wiki/IBM_Lotus_Symphony#Features ), it looks like Eclipse is for some shell, so I do not know if that is part of what they will even consider using or not. OpenOffice may be taking ideas from it without the Eclipse requirement to develop their new task pane: http://wiki.openoffice.org/wiki/Sidebar. The only thing I can tell is that there is a lot of C++ work in the sidebar branch of their repo.
I agree that Java was overused in places that it did not need to be. I personally prefer C and/or Python for work I do.
I am pleased with OpenOffice (v3.4.1). I have not seen any need to try LibreOffice personally. My take is that both are developing new features.
Regarding new features in OpenOffice, https://blogs.apache.org/OOo/entry/merging_lotus_symphony_allegro_moderato talks about what is being merged into OpenOffice from IBM's Lotus Symphony. As long as IBM continues to develop Lotus Symphony, I think that OpenOffice will benefit earlier than LibreOffice as IBM tends to do a lot with the Apache foundation. I say earlier since LibreOffice can always get the code from OpenOffice.
I am fine with these visas, however, they should make it very easy for the person hired using one of them to switch jobs at will without a slew of requirements that keep them effectively owned by the first company.
Of course, many corporations would oppose it because the people here on such a visa would be asking for much better salaries and benefits, but the only stated purpose to increase the number of visas and the whole idea of the H1-B is to get more workers. Note: I said "stated" purpose.
It is not backward, however, I should have said it goes in both directions, especially during an election year. They are both trying to put on a show for voters that the other party is bad.
I'm glad somebody likes it. The rest of the world uses bash.
As I noted at the bottom, I use zsh. You really should try it.
If you've tried to make a complex makefile, you'd see that gmake has many features that make make a lot easier. Once you've used it, going back to bsd make is a real pain.
I have used both a lot. gmake can be a pain in differences between versions when the Makefiles become complex, especially prior to 3.81. With BSD make, I can do 'make -V VARIABLE' to print what the calculated value. That is not to say it is blissful. They are different advantages and disadvantages. However, you should be using something like cmake where you do not have to care about the underlying make. They thing that really annoys me between the two is they are the opposite with regards to $.
gcc is almost 25 years old. please answer why you are using something so old when Clang is available.
Because gcc generates better code than clang does. My projects compile ~10% larger with clang. Clang is also still lagging in C++11 support. While I do not rule out switching in the future, at this time gcc is still the better choice.
You had implied that using older, stable tools was worse than using newer tools.
Regarding file size, I guess it depends upon a few factors since there are examples where MacOS binaries produced by Clang are smaller than gcc but not for Linux.
It is bad to be compatible?!? Are you saying different systems need to be incompatible else you would not use them?
I'm saying that software has changed since the 70s, and, in my opinion, for the better. If you like your old "compatible" systems, by all means, run BSD. It will likely stay just the way it is forever. I prefer progress, even if it you can't work on it exactly the same way your grandpa did.
That still confuses me. Is the KDE version that far behind on FreeBSD as compared to Linux? I can only install v4.7.3 on FreeBSD. Is that old? If you talk about shells and other command-line tools, then you are talking about the way our grandparents used systems.
What pain? Installing a few applications is painful? What do you lack with FreeBSD's utilities? tcsh is pretty decent for a shell. cp even has the same '-a' option as cp in fileutils, or is fileutils too primitive? gmake and make are different, yet make is not primitive. Anything related to the desktop has to be installed by both Linux and FreeBSD, so that is not a valid argument. gcc is almost 25 years old. Chemisor, please answer why you are using something so old when Clang is available.
They worship stability and will not make a single incompatible change, no matter how much it would improve usability.
It is bad to be compatible?!? Are you saying different systems need to be incompatible else you would not use them?
I like how you said, "Well, they can keep their stability; instead of installing Linux over BSD". You seem to be implying that Linux is unstable.
Personally, I always install zsh on any system I use even if the system has bash.
The telecommunication companies will never do that. They make much more revenue on fixed monthly fees. They love people that barely use their service yet pay for broadband via monthly fees. After what happened with landlines, fees based on usage were banned. Usage-based cell phone service scares them.
The only possibilities they may attempt is to charge extra per gigabyte over the cap or a "Super Duper We Love Your Money" unlimited plan. Both are similar to many cell phone plans.
I avoid the use of BSD licensed software because I run the risk of learning to use something in which future versions are locked behind a proprietary wall.
I may stub my toe, but I still walk. The risk to stubbing my toe is greater than software under a BSD license switching to a proprietary license. A fork can be made proprietary, still subject to the BSD license, yet it is very rare to see a project using the BSD license to make it proprietary itself.
Future versions of GPL software can also be "locked behind a proprietary wall" assuming a single entity controls the code base. Of course, the project can be forked for either license. Speaking specifically about the BSD license, have you ever used OpenSSH?
Commenting on your signature: you should stop using Python since it is under an MIT license and future versions may be released under a proprietary wall.;)
If you're going to expect cross-sharing to happen, you might as well go with the GPL, which makes it explicit. Otherwise you're giving with no guarantee that the other guy will give back. Under the BSD, Netgear gets to pick what they share and what they don't. Obviously they'll share stuff of little value to decrease maintenance costs, and not share code of high value, trading maintenance cost for exclusivity.
Since I am not tying any requirements to the code, I am sharing the code. To place an obligation on the code that someone must share back with me would not be sharing. It would be closer to barter in my opinion.
However, most projects (regardless of license) tend to be receptive to these changes.
Receptive how? If you're keeping your development process closed, the project doesn't know what you're doing, and if they do, they don't know how, so they couldn't accomodate you if they wanted.
The "receptive" part is that I know of few projects that would not be receptive to a company attempting to donate code to the project. It may not be accepted, but the project is probably not going to get angry about it.
Yes, they can. An example is a list of requirements Nvidia needs to support their module on FreeBSD amd64. The company just needs to explain why they need hooks or what the code they are donating provides.
Basically, it is sharing with all people regardless of who they are. Some companies do not have a problem with this because of your second point. To keep from having to maintain an internal fork Netgear would also be contributing back to the project. They would effectively be cross-sharing via the project.
What you've really done is turned the situation to a Prisoner's Dilemma for no good reason. And that means the game-theoretic equilibrium result is both Linksys and Netgear forking, not sharing.
Except it becomes more expensive to maintain a fork than to push the code back into the central project, however, it depends on how much and where the code will be changed. For example, if it is a separate module, then they may keep it proprietary. Nvidia is a good example of this even when the GPL is involved. If changes propagate throughout the base, then the companies will tend (granted not always) to donate the code back to the project in the hope to lower the cost of maintenance.
Well, if I was doing a router I wouldn't go with BSD, because:
1. If you contribute back, any contribution is going to be free for all. Which means that if Linksys contributes something, Netgear automatically gets to use it without any strings attached in their next product. If it happens that Linksys got something almost right, and Netgear managed to polish it to perfection in a few days, then Netgear just gained a really cool feature, courtesy of Linksys, and Linksys doesn't get to see how they did it.
Basically, it is sharing with all people regardless of who they are. Some companies do not have a problem with this because of your second point. To keep from having to maintain an internal fork Netgear would also be contributing back to the project. They would effectively be cross-sharing via the project.
Also, this condition does not apply to these Danish companies since they are accused of not sharing any code.
2. If you don't contribute back, you now have to maintain an internal fork. This is not very easy, since the people doing the public development don't know or care about what you're doing, and are perfectly free to introduce changes that completely break your modifications.
However, most projects (regardless of license) tend to be receptive to these changes.
3. If you release your changes under the GPL, the BSD supporters will whine about it for weeks.
I am sure some people will ask for a dual-license or to have the changes BSD-licensed. There may be some complaints too, but while wrapping BSD code with the GPL may be frowned upon, it is allowed under the licensed.
4. A lot of stuff out there is targeted to Linux. There's lots of software that doesn't build cleanly on Solaris due to applications using GNU extensions. I imagine the same goes for BSD as well.
Most software works on FreeBSD without patches. If patches are needed, they probably already exist in the ports tree.
I worked long ago for the founder of this company (gh, LLC) when he was in charge of the Purdue VISIONS Lab. They may have some useful technology to use.
The VISIONS Lab is probably defunct, but I found information about it.
Yet still probably the most appropriate technology for the mission, unless you have a fool-proof way of describing to someone who doesn't share any languages with you how to quickly build a Bluray player.
That would make them space pirates. The **AA would not be pleased.
Slashdot Mirror
Have there been any attempts to pass a serious budget in the senate regardless of what the Republicans are doing? I have heard of budgets being brought forward that neither party was going to support which I would call political versus a serious budget.
I hate politics.
For what they have done, I think it is a good thing since it looks like a lot of the changes are bug fixes where language would not matter.
From the description of Lotus Symphony ( https://en.wikipedia.org/wiki/IBM_Lotus_Symphony#Features ), it looks like Eclipse is for some shell, so I do not know if that is part of what they will even consider using or not. OpenOffice may be taking ideas from it without the Eclipse requirement to develop their new task pane: http://wiki.openoffice.org/wiki/Sidebar. The only thing I can tell is that there is a lot of C++ work in the sidebar branch of their repo.
I agree that Java was overused in places that it did not need to be. I personally prefer C and/or Python for work I do.
I am pleased with OpenOffice (v3.4.1). I have not seen any need to try LibreOffice personally. My take is that both are developing new features.
Regarding new features in OpenOffice, https://blogs.apache.org/OOo/entry/merging_lotus_symphony_allegro_moderato talks about what is being merged into OpenOffice from IBM's Lotus Symphony. As long as IBM continues to develop Lotus Symphony, I think that OpenOffice will benefit earlier than LibreOffice as IBM tends to do a lot with the Apache foundation. I say earlier since LibreOffice can always get the code from OpenOffice.
I am fine with these visas, however, they should make it very easy for the person hired using one of them to switch jobs at will without a slew of requirements that keep them effectively owned by the first company.
Of course, many corporations would oppose it because the people here on such a visa would be asking for much better salaries and benefits, but the only stated purpose to increase the number of visas and the whole idea of the H1-B is to get more workers. Note: I said "stated" purpose.
How does that factor in the tax breaks (income tax and mortgage deductions) that California takes advantage of? A CNN bit about it: http://money.cnn.com/2012/12/06/news/economy/state-local-tax-deductions/index.html
Do they really have a surplus? http://www.nbcbayarea.com/news/local/Does-California-Really-Have-a-Budget-Surplus__Bay-Area.html
I just wanted to mention that KeePassX runs on UNIX systems.
I think OpenOffice is under the ASF. Oracle is no longer involved is my understanding.
It is not backward, however, I should have said it goes in both directions, especially during an election year. They are both trying to put on a show for voters that the other party is bad.
If most Republicans were against it, then most Democrats would have been for it. Define *it* to be almost anything.
tcsh is pretty decent for a shell
I'm glad somebody likes it. The rest of the world uses bash.
As I noted at the bottom, I use zsh. You really should try it.
If you've tried to make a complex makefile, you'd see that gmake has many features that make make a lot easier. Once you've used it, going back to bsd make is a real pain.
I have used both a lot. gmake can be a pain in differences between versions when the Makefiles become complex, especially prior to 3.81. With BSD make, I can do 'make -V VARIABLE' to print what the calculated value. That is not to say it is blissful. They are different advantages and disadvantages. However, you should be using something like cmake where you do not have to care about the underlying make. They thing that really annoys me between the two is they are the opposite with regards to $.
gcc is almost 25 years old. please answer why you are using something so old when Clang is available.
Because gcc generates better code than clang does. My projects compile ~10% larger with clang. Clang is also still lagging in C++11 support. While I do not rule out switching in the future, at this time gcc is still the better choice.
You had implied that using older, stable tools was worse than using newer tools.
Regarding file size, I guess it depends upon a few factors since there are examples where MacOS binaries produced by Clang are smaller than gcc but not for Linux.
It is bad to be compatible?!? Are you saying different systems need to be incompatible else you would not use them?
I'm saying that software has changed since the 70s, and, in my opinion, for the better. If you like your old "compatible" systems, by all means, run BSD. It will likely stay just the way it is forever. I prefer progress, even if it you can't work on it exactly the same way your grandpa did.
That still confuses me. Is the KDE version that far behind on FreeBSD as compared to Linux? I can only install v4.7.3 on FreeBSD. Is that old? If you talk about shells and other command-line tools, then you are talking about the way our grandparents used systems.
What pain? Installing a few applications is painful? What do you lack with FreeBSD's utilities? tcsh is pretty decent for a shell. cp even has the same '-a' option as cp in fileutils, or is fileutils too primitive? gmake and make are different, yet make is not primitive. Anything related to the desktop has to be installed by both Linux and FreeBSD, so that is not a valid argument. gcc is almost 25 years old. Chemisor, please answer why you are using something so old when Clang is available.
They worship stability and will not make a single incompatible change, no matter how much it would improve usability.
It is bad to be compatible?!? Are you saying different systems need to be incompatible else you would not use them?
I like how you said, "Well, they can keep their stability; instead of installing Linux over BSD". You seem to be implying that Linux is unstable.
Personally, I always install zsh on any system I use even if the system has bash.
Or are they GPS satellites "equipped with nuclear missiles and a laser cannon"?
I used to work in the same building as these people. I even worked with a couple of them on different products.
While I have not used/seen their products, they may offer something useful.
http://www.gh-accessibility.com/
So, I wonder, what the Gravity was thinking when It created Adam and Eve?
I wonder if opposites attract?
The telecommunication companies will never do that. They make much more revenue on fixed monthly fees. They love people that barely use their service yet pay for broadband via monthly fees. After what happened with landlines, fees based on usage were banned. Usage-based cell phone service scares them.
The only possibilities they may attempt is to charge extra per gigabyte over the cap or a "Super Duper We Love Your Money" unlimited plan. Both are similar to many cell phone plans.
To MIB, "Orion" is a cat.
Two for the price of one joke. :)
I avoid the use of BSD licensed software because I run the risk of learning to use something in which future versions are locked behind a proprietary wall.
I may stub my toe, but I still walk. The risk to stubbing my toe is greater than software under a BSD license switching to a proprietary license. A fork can be made proprietary, still subject to the BSD license, yet it is very rare to see a project using the BSD license to make it proprietary itself.
Future versions of GPL software can also be "locked behind a proprietary wall" assuming a single entity controls the code base. Of course, the project can be forked for either license. Speaking specifically about the BSD license, have you ever used OpenSSH?
Commenting on your signature: you should stop using Python since it is under an MIT license and future versions may be released under a proprietary wall. ;)
The FreeBSD Nvidia 64-bit driver should be coming soon (a few weeks minimum): http://www.nvnews.net/vbulletin/showpost.php?p=2129411&postcount=445
If you're going to expect cross-sharing to happen, you might as well go with the GPL, which makes it explicit. Otherwise you're giving with no guarantee that the other guy will give back. Under the BSD, Netgear gets to pick what they share and what they don't. Obviously they'll share stuff of little value to decrease maintenance costs, and not share code of high value, trading maintenance cost for exclusivity.
Since I am not tying any requirements to the code, I am sharing the code. To place an obligation on the code that someone must share back with me would not be sharing. It would be closer to barter in my opinion.
However, most projects (regardless of license) tend to be receptive to these changes.
Receptive how? If you're keeping your development process closed, the project doesn't know what you're doing, and if they do, they don't know how, so they couldn't accomodate you if they wanted.
The "receptive" part is that I know of few projects that would not be receptive to a company attempting to donate code to the project. It may not be accepted, but the project is probably not going to get angry about it.
Yes, they can. An example is a list of requirements Nvidia needs to support their module on FreeBSD amd64. The company just needs to explain why they need hooks or what the code they are donating provides.
What you've really done is turned the situation to a Prisoner's Dilemma for no good reason. And that means the game-theoretic equilibrium result is both Linksys and Netgear forking, not sharing.
Except it becomes more expensive to maintain a fork than to push the code back into the central project, however, it depends on how much and where the code will be changed. For example, if it is a separate module, then they may keep it proprietary. Nvidia is a good example of this even when the GPL is involved. If changes propagate throughout the base, then the companies will tend (granted not always) to donate the code back to the project in the hope to lower the cost of maintenance.
Well, if I was doing a router I wouldn't go with BSD, because:
1. If you contribute back, any contribution is going to be free for all. Which means that if Linksys contributes something, Netgear automatically gets to use it without any strings attached in their next product. If it happens that Linksys got something almost right, and Netgear managed to polish it to perfection in a few days, then Netgear just gained a really cool feature, courtesy of Linksys, and Linksys doesn't get to see how they did it.
Basically, it is sharing with all people regardless of who they are. Some companies do not have a problem with this because of your second point. To keep from having to maintain an internal fork Netgear would also be contributing back to the project. They would effectively be cross-sharing via the project.
Also, this condition does not apply to these Danish companies since they are accused of not sharing any code.
2. If you don't contribute back, you now have to maintain an internal fork. This is not very easy, since the people doing the public development don't know or care about what you're doing, and are perfectly free to introduce changes that completely break your modifications.
However, most projects (regardless of license) tend to be receptive to these changes.
3. If you release your changes under the GPL, the BSD supporters will whine about it for weeks.
I am sure some people will ask for a dual-license or to have the changes BSD-licensed. There may be some complaints too, but while wrapping BSD code with the GPL may be frowned upon, it is allowed under the licensed.
4. A lot of stuff out there is targeted to Linux. There's lots of software that doesn't build cleanly on Solaris due to applications using GNU extensions. I imagine the same goes for BSD as well.
Most software works on FreeBSD without patches. If patches are needed, they probably already exist in the ports tree.
It could be a problem with a reverse proxy. Actually, I just needed to remove the ".nyud.net:8080" from the URL to get it to work.
I worked long ago for the founder of this company (gh, LLC) when he was in charge of the Purdue VISIONS Lab. They may have some useful technology to use.
The VISIONS Lab is probably defunct, but I found information about it.
Yet still probably the most appropriate technology for the mission, unless you have a fool-proof way of describing to someone who doesn't share any languages with you how to quickly build a Bluray player.
That would make them space pirates. The **AA would not be pleased.