It's not that the human brain can't grasp the issues -- it's that most of the population cares more about which team won yesterday's game and who screwed who on the soap operas. Most humans are very egocentric, small-minded creatures who don't really give a shit about anything that doesn't immediately affect them personally.
It's not that they can't conceive of longer term or wider scaled things. They're just selfish pricks.
Yes, my aging P4 3.8 GHz with 800MHz DDR2 memory is "slow", but when I think back on "the old days" when we only did builds over the weekends in the age of 1MHz processors, it's pretty darned snappy.
Plus when I tune code, I get to see an improvement.:D
I disagree. You're going to see a surge because the crackers are presuming that anyone still running a 2003 system have also been lax about applying security patches -- and the odds are, they're going to be right, and they're going to get in.
Since the 2000's, every box I've built has been specced to about $1200 in parts. One of the reasons this one in particular is going to be so pricey is going for the fastest RAM the mobo will support, the fastest CPU I can afford (in terms of single-threaded performance), and an SSD drive because such a fast CPU would be IO bound on a physical hard drive when running my pet project.
Sure I could go with a lower end CPU and stuff, but the odds are that by the time I'm actually ready to buy, another CPU or two will have come on the market and prices for the CPU should drop to about half what they are now. I expect SSD prices to come down as well, saving a few more bucks. So I'm expecting the actual purchase price in the January-February time frame to be about $900 (Canadian.)
I neglected to mention that this old beast *is* starting to fail, and ever more frequently. RAM tests out clean -- I think the CPU is just finally starting to fail randomly. Recent patches to Ubuntu LTS 14.04.2 have taken care of the display driver/KDE crashes, but it still will periodically just "lock up" completely without producing a white-out screen. Fortunately the lock-ups are only about once or twice a month while under heavy load for an hour or so.
Still, it's far more reliable than Win2K or WinXP ever were -- those boxen had to be hard-booted at least once every day or two. Things *have* improved over the years.
Now if Oracle would only stabilize JDK 8. Update 45 crashes like a fiend on large ant builds, and even the runtime fails so often that I have to do 5-10 runs of one particularly large job before it will run to completion.
Fortunately, time is one thing I have in plenty on disability. Were I using this box for work, I'd have the coin and justification for replacing it *now*. In the meantime, I save as much as I can as often as I can towards that future purchase.:D
I still *run* a P4 3.8GHz as my main Linux box. Sure it heats up the apartment like a space heater, but it works. Until it stops working, I won't be spending $1200 on a new box...:P
The problem is that MBAs are hired to manage teams they have no experience with. Having a general knowledge of the business is not going to help you manage the tech support team, it's not going to help you manage the product development team that requires in-depth knowledge of the product, and it's not going to help you manage a group of web coders who deal with technical details.
The only thing an MBA helps you "manage" is prioritizing the user community requirements, and seeing as it's not the manager's job to set the project schedule, that helps no one.
I've met ONE MBA who was a good manager, and he was a good manager before he got his MBA. Nor did he change his management style after completing his MBA. From a management perspective, his MBA was a complete and utter waste of time.
Every other MBA manager I've dealt with in my life was cut from the same cloth: "respect me because I have an MBA."
Nobody except Android app developers really gives a rat's fat ass what happens to Google's bastardization of Java. Do you really think all those line of business and corporate web applications written with Java and JEE are going to go away because Google gets kicked to the curb?
You're not a "real" programmer until you've rolled your own framework or language. Sooner or later, everyone worth their salt gets some "bright ideas" and gives it a try.:)
Bullshit. There are many reasons for tracking assets, and different information required for the tracking, which is the crux of the original article. Accounting for depreciations is only one of those requirements, and no more important than any other.
If the accounting department were doing their job properly, they would already have a system in place for tracking receipt of new equipment and subsequent depreciation. They would not be relying on an asset tracking/inventory system to do the job for them.
I don't understand this presumption that you need 3D acceleration to have a usable desktop. There are plenty of older style cards that will work just fine with desktops that don't require 3D acceleration.
You may want 3D acceleration and you may want to play games, but that isn't required for a "usable desktop."
There are far more companies and individuals with APIs for their products that allow extension and customization who are not "standards" than there are products whose interfaces have been explicitly coded to published standards whose licenses grant other parties the right to code to them.
Take, for example, SalesForce. They have an API. But they'd sue the schite out of you if you tried to claim it is a "standard" and use their API in a competing product.
Whether an API is a "standard" or not is entirely up to the publisher of the API. The default in North America is not that things fall under the public domain, but that the rights remain with the publisher unless they've granted explicit authorization.
As to the question of whether you should be able to copyright an API, I don't have any doubts that it should be copyrightable. See my point on the number of companies who rely on their interfaces not being clonable by competitors.
A lot of effort goes into a well written and thought out interface. In fact, the interface is often half the design of a product. It deserves protection from those who think they can take anything they want if they just want it badly enough.
You're making the mistake of confusing programming to an API with the API itself. The arguments to a method of an API have named variables, not a wildcard list of arguments. They are well-defined and specific, even if they take a generic list of objects as their trailing argument, the fact that it takes a list of objects is specified.
As to others who have questioned what it takes to qualify as a "standard":
Unless an API is explicitly published for the purpose of use by alternative implementations, it is proprietary. Can you imagine what would happen if you tried to clone the SalesForce API in a competing product? It's all up to the interpretation and licensing granted by the publisher of the API as to whether it is a "standard" for competing products or a "proprietary" interface only for use by their own product line.
It doesn't matter whether it is designed by a committee, designed by an individual, designed by a corporation, or designed by a "regular" standard's body. What matters is the intent of the publication license, if any.
Remember that the default for published works is that all rights are reserved by the copyright holder unless they grant permissions, not that it is under the public domain.
Yet if you think of an API as being the chapter-titles of a book, what you're saying is that it's ok to steal all the titles from an existing work and write your own chapter contents. I don't see where or why the API of a system would not be under copyright -- the whole point of licenses like the LGPL is to let you use the interface explicitly whereas the GPL denies you the right to use the interface without publishing your code.
Just because someone wants to use your API really, really badly doesn't mean they have the legal right to do so any more than they have the right to use the rest of your code without permission.
Something which is a published standard like the ABIs for Linux are another matter entirely -- the interface is treated as an abstract work separate from the implementation. But I don't see anything in the way Java is licensed that would lead to the interpretation that it's API is a standard managed by some oversight organization instead of a corporate entity.
Slashdot Mirror
It's not that the human brain can't grasp the issues -- it's that most of the population cares more about which team won yesterday's game and who screwed who on the soap operas. Most humans are very egocentric, small-minded creatures who don't really give a shit about anything that doesn't immediately affect them personally.
It's not that they can't conceive of longer term or wider scaled things. They're just selfish pricks.
Damnit! How can it be a "contest" when the same people always win? :P
Yes, my aging P4 3.8 GHz with 800MHz DDR2 memory is "slow", but when I think back on "the old days" when we only did builds over the weekends in the age of 1MHz processors, it's pretty darned snappy.
Plus when I tune code, I get to see an improvement. :D
I disagree. You're going to see a surge because the crackers are presuming that anyone still running a 2003 system have also been lax about applying security patches -- and the odds are, they're going to be right, and they're going to get in.
I think the more likely issue is a failing PSU or the CPU itself.
I just replaced the CPU cooler last year, though, so I doubt the paste has gone bad.
Capacitors -- unlikely. They're the square block type mil-spec capacitors on this mobo, not the tube-type with electrolytic fluid.
Since the 2000's, every box I've built has been specced to about $1200 in parts. One of the reasons this one in particular is going to be so pricey is going for the fastest RAM the mobo will support, the fastest CPU I can afford (in terms of single-threaded performance), and an SSD drive because such a fast CPU would be IO bound on a physical hard drive when running my pet project.
Sure I could go with a lower end CPU and stuff, but the odds are that by the time I'm actually ready to buy, another CPU or two will have come on the market and prices for the CPU should drop to about half what they are now. I expect SSD prices to come down as well, saving a few more bucks. So I'm expecting the actual purchase price in the January-February time frame to be about $900 (Canadian.)
I neglected to mention that this old beast *is* starting to fail, and ever more frequently. RAM tests out clean -- I think the CPU is just finally starting to fail randomly. Recent patches to Ubuntu LTS 14.04.2 have taken care of the display driver/KDE crashes, but it still will periodically just "lock up" completely without producing a white-out screen. Fortunately the lock-ups are only about once or twice a month while under heavy load for an hour or so.
Still, it's far more reliable than Win2K or WinXP ever were -- those boxen had to be hard-booted at least once every day or two. Things *have* improved over the years.
Now if Oracle would only stabilize JDK 8. Update 45 crashes like a fiend on large ant builds, and even the runtime fails so often that I have to do 5-10 runs of one particularly large job before it will run to completion.
Fortunately, time is one thing I have in plenty on disability. Were I using this box for work, I'd have the coin and justification for replacing it *now*. In the meantime, I save as much as I can as often as I can towards that future purchase. :D
Swift for Linux piques my interest...
I still *run* a P4 3.8GHz as my main Linux box. Sure it heats up the apartment like a space heater, but it works. Until it stops working, I won't be spending $1200 on a new box... :P
Gee, then I guess my whole high school class was comprised of arcade-going "nerds." The same as every other town around here.
Arcades were the place to hang out.
The problem is that MBAs are hired to manage teams they have no experience with. Having a general knowledge of the business is not going to help you manage the tech support team, it's not going to help you manage the product development team that requires in-depth knowledge of the product, and it's not going to help you manage a group of web coders who deal with technical details.
The only thing an MBA helps you "manage" is prioritizing the user community requirements, and seeing as it's not the manager's job to set the project schedule, that helps no one.
I've met ONE MBA who was a good manager, and he was a good manager before he got his MBA. Nor did he change his management style after completing his MBA. From a management perspective, his MBA was a complete and utter waste of time.
Every other MBA manager I've dealt with in my life was cut from the same cloth: "respect me because I have an MBA."
That's bullshit. You want my respect: earn it.
Nobody except Android app developers really gives a rat's fat ass what happens to Google's bastardization of Java. Do you really think all those line of business and corporate web applications written with Java and JEE are going to go away because Google gets kicked to the curb?
You're not a "real" programmer until you've rolled your own framework or language. Sooner or later, everyone worth their salt gets some "bright ideas" and gives it a try. :)
Bullshit. There are many reasons for tracking assets, and different information required for the tracking, which is the crux of the original article. Accounting for depreciations is only one of those requirements, and no more important than any other.
If the accounting department were doing their job properly, they would already have a system in place for tracking receipt of new equipment and subsequent depreciation. They would not be relying on an asset tracking/inventory system to do the job for them.
You overstate and overestimate your importance.
1. Customers
2. Sales/Marketing
3. Customer support
4. Product development and production
Those are the "make or break" of a successful business, not the overhead/expense of accounting.
And to someone who works in a data center, the most important things are tracking power draw, heat dissipation, and cooling requirements.
There is no one solution that fits all needs, and every user (like you) is going to claim that their needs are "priority one."
If you're an MBA, remember that to everyone who works for you, that stands for "Moronic, Bullshitting Asshole".
The "pragmatic" solution would be to stop bitching that the BLOBs are proprietary and to just use what is made available to you.
You can run the SVGA drivers with virtually any modern 3D card. If you're that paranoid about the BLOBs, you have an option. How is that "wrong"?
It's not like Intel, AMD, or NVidia are going to start publishing the source code for their BLOBs just because you're paranoid about their contents.
If you can run a given desktop with an SVGA driver, then you do not "require" 3D acceleration to use it.
I don't understand this presumption that you need 3D acceleration to have a usable desktop. There are plenty of older style cards that will work just fine with desktops that don't require 3D acceleration.
You may want 3D acceleration and you may want to play games, but that isn't required for a "usable desktop."
There are far more companies and individuals with APIs for their products that allow extension and customization who are not "standards" than there are products whose interfaces have been explicitly coded to published standards whose licenses grant other parties the right to code to them.
Take, for example, SalesForce. They have an API. But they'd sue the schite out of you if you tried to claim it is a "standard" and use their API in a competing product.
Whether an API is a "standard" or not is entirely up to the publisher of the API. The default in North America is not that things fall under the public domain, but that the rights remain with the publisher unless they've granted explicit authorization.
As to the question of whether you should be able to copyright an API, I don't have any doubts that it should be copyrightable. See my point on the number of companies who rely on their interfaces not being clonable by competitors. A lot of effort goes into a well written and thought out interface. In fact, the interface is often half the design of a product. It deserves protection from those who think they can take anything they want if they just want it badly enough.
You're making the mistake of confusing programming to an API with the API itself. The arguments to a method of an API have named variables, not a wildcard list of arguments. They are well-defined and specific, even if they take a generic list of objects as their trailing argument, the fact that it takes a list of objects is specified.
As to others who have questioned what it takes to qualify as a "standard":
Unless an API is explicitly published for the purpose of use by alternative implementations, it is proprietary. Can you imagine what would happen if you tried to clone the SalesForce API in a competing product? It's all up to the interpretation and licensing granted by the publisher of the API as to whether it is a "standard" for competing products or a "proprietary" interface only for use by their own product line.
It doesn't matter whether it is designed by a committee, designed by an individual, designed by a corporation, or designed by a "regular" standard's body. What matters is the intent of the publication license, if any.
Remember that the default for published works is that all rights are reserved by the copyright holder unless they grant permissions, not that it is under the public domain.
Yet if you think of an API as being the chapter-titles of a book, what you're saying is that it's ok to steal all the titles from an existing work and write your own chapter contents. I don't see where or why the API of a system would not be under copyright -- the whole point of licenses like the LGPL is to let you use the interface explicitly whereas the GPL denies you the right to use the interface without publishing your code.
Just because someone wants to use your API really, really badly doesn't mean they have the legal right to do so any more than they have the right to use the rest of your code without permission.
Something which is a published standard like the ABIs for Linux are another matter entirely -- the interface is treated as an abstract work separate from the implementation. But I don't see anything in the way Java is licensed that would lead to the interpretation that it's API is a standard managed by some oversight organization instead of a corporate entity.
Why can't Google just ship an OpenJDK build for ARM instead of screwing around with breaking the portability contract of the byte code?
This whole situation is the most asinine pissing match I have seen since SCO...