Just because something might be judged illegal if it went to court doesn't mean people will avoid it. Removing the name of someone from the credits list of a program after they leave is standard operating procedure at a lot of places. If it was done as work for hire, which includes most employee situations, the company owns the copyright, not you. They can do whatever they like with it, including altering the credits.
Telling a contributor that they shouldn't be submitting the code they worked on is a great way to kill creativity and drive people away from the project.
Know what's an even better way to drive people away from a project? Never ship a high quality release, so your users give up and stop deploying your program. Adding immature developers to a project isn't a gain either, and that's what this whole "you'll kill my creativity" angle is--a mix of immaturity and ego.
You can adopt tactics toward tight change control to try and reduce bug count, or you can let developers work with an unbounded target where people can change things forever. But you can't do both, and Linus is running a project where it's important to ship releases. In every project there are some developers with an ego or authority issue, ones who think the rules around release candidates don't apply to them, that their changes are important, and surely they cannot introduce bugs. But that's how amateur coders think, and adding people with that attitude doesn't benefit any serious project.
ASLR has been usefully complicating enough vulnerabilities to have proven it's worthwhile. At this point it's quite near being an industry standard for any system that follows good security practices. It's really not credible to reject it anymore as too complicated to risk bothering with. Yes, some of the issues can be addressed more deeply, too, but security should be layered and redundant.
A major cause for why there are less exploits on the *BSD kernels is that the rate of innovation is so low. New and rapidly changing code is where a lot of security bugs come from. If Linux kernel development did a lot less work each year and has a smaller feature base, they could spend a lot more time on hardening too. The *BSD approach isn't a bad one, but it's a trade-off with good and bad sides to it.
Re:only recommended if you need to stay on 8.x
on
FreeBSD 8.4 Released
·
· Score: 1
Both Linux and FreeBSD allow building exactly what you want from source if you want to. It's not quite right to say one gives more control over what goes into the system. FreeBSD has a different set of trade-offs in how things are packaged, and their default choices and packaging distribution choices are nice for some purposes. But ultimately there's nothing you can match in multiple Linux distributions if you feel like it. There's always Linux from Scratch if you're hardcore about controlling what goes into your system.
Yeah, looks like we're all still stuck writing our own Jethro in drag/Han Solo wrestling fan fic. What a relief, for a minute there I was worried all of my Miss Hathaway drawings were going to be wasted!
The Torah and Talmud don't proscribe against electricity - but the notion of building an item (for lights, think of turning one on as building a circuit). Similarly, shutting lights off is destroying that circuit.
And then one day someone realized that breathing involves building carbon dioxide by destroying oxygen, so all strict observers of the Torah stopped that and died the next Shabbat. The End.
If you want to come up with a bunch of arbitrary rules for how your club should run and then argue about them with your spare time, bully for you. But don't try and act like there's real logic behind them.
Finding out fast where the disk space went is exactly the problem that's best solved with scripting. An admin who goes poking around the disk tree manually instead of launching a tool to help figure out what's wrong is a pretty poor one. Saying that path "twaddled around programming" tells me you've failed my interview. If you can't throw together a quick script to look for disk hogs in seconds using a UNIX tools pipeline, faster than you can click through even a few levels of directories with a standard UI, you have no place as an administrator in my world. Administrators who don't approach their work like a software developer, constantly building tools to improve their efficiency, they don't scale well enough to handle important servers.
You're making a pretty bold claim about open source in general from a small set of data. There's a perfectly valid way to evolve interfaces over time without having an explicit design up front. One way to do that is to iterate based on user feedback, and that's where projects like GNOME have failed the worst. That's their problem though, not the problem of all open source development. What I expect to happen with most of the bugs filed by this author is that they'll be marked "not a bug, you're doing it wrong" and that's the end of it. That persistent attitude is fundamentally why GNOME3 sucks, not because it was designed badly.
And so-called usability experts are part of the problem here too. For every Tufte there's a thousand mediocre designers, and from how that's worked out on commercial products they don't seem to listen to feedback either. The common trap desktop designers fall into is that if you aim for a desktop that is simple for a less technical person, a weak UI designer will cut out options and complicated features every time. The GNOME development team is famous for taking things that used to be customizable and removing both the less popular options and the configuration interface, thinking that simplification helps everyone. The idea that multiple workflows might be valuable because not everyone interacts with their computer exactly the same way seems lost on everyone doing that sort of work.
Open source tools should listen to their users, and weigh the habits of its most productive users just as heavily as the middle of the road ones. The people who get things done by developing programs for others are not to be scoffed at; they're part of why open source development has come so far. Believing in focus group and UI experts and flipping off feedback from outside users is leading to more spectacular failures each year lately. Windows Metro, Ubuntu's Unity, and GNOME 3 can all take their teams that ignore feedback from their advanced users and become irrelevant with that approach; they won't be missed. Apple seems heading the same way too, as they pull IOS elements into their desktop that nobody asked for, in some misplaced idea that tablet and desktop UIs need to be similar.
Sub-pixel rendering is heavily covered by Microsoft Patents. Blame them, or the rest of the industry that's stalling innovation with software patents; Apple does the same thing. Sub-pixel rendering is math you graph, and the idea that it's patentable is ridiculous. But since it is a real problem, free software can either avoid the major patents or risk getting pulled into a patent war that wastes a lot of money. Right now RedHat is avoiding them.
There is a whole section to that article describing why Steve Gibson's piece on this subject was worthless. You have to specifically attack the claims of the specific patent with prior art to kill it off, not just reference something that kinda sorta did something similar before.
And if you run all of your servers on VMs, it can be easy to roll back to a state where you're ready to do the SQL/Exchange setup with the time limit again. The only that has made my toying with Windows systems tolerable is being able to torpedo them and go back to a nice known state I saved a snapshot of.
Some eval software is smart enough to personally identify your hardware and generate a demo key based on it. If you ask for a second one, you won't get one for that hardware. The things used to collect that personally identifiable info are also easier to change on a VM install too. I have gotten around nagware that used the MAC address as a unique key for who has a demo license by just changing the MAC address on the VM. On Windows, knowing how you can modify a server without actually losing its activation is a real-world job skill too; it's not just cheapskate knowledge.
And by MS cloud, I mean a non user serviceable cloud run by Jeffrey Snover level powershelling autobots
Those are actually Decepticons.
The idea of becoming serious about Hyper-V is worth considering. Knowing a lot about virtualization is an overlapping skill set with considerable value of its own. It may be too much to chew off at once though. If the positions someone has their eye on involve Exchange and SQL, it's quite reasonable to gain basic skills at setting up virtual test servers and then moving onto those things. You can easily get lost in virtual systems for a long time, but that alone is hard to turn into a useful career path. A virtualization expert who is also a fair DBA is not going to be considered a skilled DBA by anyone, whereas a skilled DBA who knows a bit about virtualization can easily get a job.
I can usefully interview for sysadmins with a single question: "if you were paged that a [type of server used at the company] system is out of disk space, what would you do?" There's no right or wrong answer, but more experienced people will normally include a long list of things they've run into when that exact situation hit in previous work. Great answers include details on how to write a shell/Perl/Python program looking for common disk hogs. Bad ones discuss how to click on icons to check disk space.
In theory I can be fooled here by someone who just studied the topic deeply enough. But anyone who's done enough of that to rattle off a good sized list is someone likely to pick things up on the job too. And that's the most valuable skill of all.
The normal range for computer consulting companies is to charge 3 to 5X as much as the consultant is being paid. You might find an extremely lean one that operates at only 2X the consultant rates, especially if they are paying the consultant at 1099 rates (without withholding) rather than W2 ones. But having been on both sides of this for a while it's hard to be that generous to the consultants at most companies.
If the company is helping find leads and paying you sometimes when you'd otherwise be idle, all of this is quite reasonable. The main time I have found that overhead rate to be unfair to the consultant is when you're being pushed to work for a consulting company by the client, usually to keep their paperwork to a minimum. $BIG_CLIENT often has a contract with $TEMP_FIRM so that they only have one staffing company for consulting work. It's common in that position to discover $BIG_CLIENT advertising for positions, but requiring that you go through $TEMP_FIRM anyway in order to do work for them. And when the job is over, you're out. In that situation, it's reasonable to say $TEMP_FIRM doesn't deserve so much of your rate. Typically you have minimal negotiating power there though, because the only other option is to walk away from the work altogether.
Most manufacturers outside of the German cars are using systems developed by KeeLoq, so a vulnerability in that would impact a large number of vehicles. Parts of the encryption method have been attacked by researchers, with papers like How To Steal Cars. Some of these papers point out that the exact security mechanisms used by manufacturers on top of KeyLoq's hardware are not public, so turning the theoretical hacks into a working device is still hard even with these issues identified. Based on that FAQ, KeeLoq itself seems secure against anything but very knowledgeable attackers with significant resources--they're quoting months of work to find a real-world vulnerability. However, we can't be sure that a specific implementation of the security approach wasn't weakened by a manufacturer mistake. I wouldn't place a large bet on that though. Someone like a car manufacturer wants to be able to say they passed the risk to someone expert in this area. If they start customizing things to add back doors, they're going to lose any ability to blame KeeLoq if there's a nasty vulnerability.
The Tron arcade game was great though, also released in 1982. And after the terrible ET game, the early arcade games based on Star Wars and Star Trek from 1983 are all great fun to play. Not all of the home games based on movies are bad either. The Atari 2600 "Star Wars: The Empire Strikes Back" was decent.
Yeah, I was just blowing dust out of a not easily replaced original IBM PC from 1982 at a manufacturing site last week, and I sure wouldn't call even that antique.
Serial ports are a pretty easy thing to deal with. In PC land it's stuff on old ISA cards that are the real nightmare. One of those is what's keeping that PC alive, and we can't even replace the system with a newer model because the software is only timed right at 4.77Mhz. I'm just glad I don't have any MCA bus hardware to worry about anymore.
Most of my computer interfacing work crosses over into analog signals, and I'm not always in the mood to wire up circuitry to make a Pi talk to them. And some days I don't want two boards talking to one another via some interface I maintain; I'd like to just have one board to deal with and move on. That's the mindset the UDOO is targeting.
The cool part about the Raspberry Pi is that it runs Linux. Its ability to interface with non computing hardware could be better.
The cool part about the Arduino is its analog and digital I/O interfaces. It has standard connectors for that purpose, beaten into useful form via a lot of people over the years, and there's even a good sized industry providing parts that plug into them. I can wander to my local Microcenter and get all sorts of Arduino parts nowadays.
The combination of the two, running Linux but with the Arduino interfaces, can cost more than both chips combined and still be worthwhile. That's what the UDOO is trying to do. If your goal is to have a generic system that can do all sorts of hacking, this is a possibility for such a device. Maybe the price will even come down over time to have less of a premium.
Related tangent: if you beat "Injustice: Gods Among Us", along with the credits for the graphics engine, physics engine, etc., at the very end you'll find the very viral and unusual OpenSSL license. Even Batman has to yield to weird software licenses!
Skills for game development are fun, but the at best 1% of the software development market they represent is not something a budding programmer should worry about too much.
Getting a CS degree involves a number of things that aren't just software development. Part of the reason degrees are considered valuable is because they prove people are willing to stick to the end of a project even if there are parts that are difficult for them. Almost everyone has something in a solid degree program that's hard for them. I breezed through math but struggled with chemistry. Sucked it up and worked through the parts that didn't come easy, because that's part of what degree programs are supposed to be about.
Your case then is that because some code is unreadable, obfuscated code might be just as useful as the original. That's possible, but you're arguing about an edge case. When someone is providing source code for a program in order to make it free, they should provide the same version of that code that development is done against, period. In some cases that code will be unreadable, and the maintainer has to spend a lot of time to change it too. But in many much more common situations, the code is much easier to read and work with in its original form, and these minimization/obfuscation steps make it harder to read or use.
Switching to OpenDocument won't make format incompatibilities go away; it will probably make them worse. The page rendering in OpenOffice is not the same as Microsoft Office, and both suites can change formatting between versions. Formatting on Linux and Windows isn't quite the same either, because of subtle font changes as a start. If you want formatting that is relatively stable, you can't use an Office-style tool at all. They are just not well suited for the job.
Even if you did have a tool that never screwed things up, I am confident you'll still find users who break documents by having no idea how formatting works. I've lost track of how many documents I've had to fix because the user did indenting with a hard carriage return and hitting space a few times. And then there's people who format tables by putting spaces between each column .
Slashdot Mirror
Just because something might be judged illegal if it went to court doesn't mean people will avoid it. Removing the name of someone from the credits list of a program after they leave is standard operating procedure at a lot of places. If it was done as work for hire, which includes most employee situations, the company owns the copyright, not you. They can do whatever they like with it, including altering the credits.
Telling a contributor that they shouldn't be submitting the code they worked on is a great way to kill creativity and drive people away from the project.
Know what's an even better way to drive people away from a project? Never ship a high quality release, so your users give up and stop deploying your program. Adding immature developers to a project isn't a gain either, and that's what this whole "you'll kill my creativity" angle is--a mix of immaturity and ego.
You can adopt tactics toward tight change control to try and reduce bug count, or you can let developers work with an unbounded target where people can change things forever. But you can't do both, and Linus is running a project where it's important to ship releases. In every project there are some developers with an ego or authority issue, ones who think the rules around release candidates don't apply to them, that their changes are important, and surely they cannot introduce bugs. But that's how amateur coders think, and adding people with that attitude doesn't benefit any serious project.
ASLR has been usefully complicating enough vulnerabilities to have proven it's worthwhile. At this point it's quite near being an industry standard for any system that follows good security practices. It's really not credible to reject it anymore as too complicated to risk bothering with. Yes, some of the issues can be addressed more deeply, too, but security should be layered and redundant.
A major cause for why there are less exploits on the *BSD kernels is that the rate of innovation is so low. New and rapidly changing code is where a lot of security bugs come from. If Linux kernel development did a lot less work each year and has a smaller feature base, they could spend a lot more time on hardening too. The *BSD approach isn't a bad one, but it's a trade-off with good and bad sides to it.
Both Linux and FreeBSD allow building exactly what you want from source if you want to. It's not quite right to say one gives more control over what goes into the system. FreeBSD has a different set of trade-offs in how things are packaged, and their default choices and packaging distribution choices are nice for some purposes. But ultimately there's nothing you can match in multiple Linux distributions if you feel like it. There's always Linux from Scratch if you're hardcore about controlling what goes into your system.
Yeah, looks like we're all still stuck writing our own Jethro in drag/Han Solo wrestling fan fic. What a relief, for a minute there I was worried all of my Miss Hathaway drawings were going to be wasted!
Worshippers at the cult of capitalism, who use their money to repress others and foster anti-society tragedies of the commons, they are pretty bad.
Wait, were you talking about the Amish?
The Torah and Talmud don't proscribe against electricity - but the notion of building an item (for lights, think of turning one on as building a circuit). Similarly, shutting lights off is destroying that circuit.
And then one day someone realized that breathing involves building carbon dioxide by destroying oxygen, so all strict observers of the Torah stopped that and died the next Shabbat. The End.
If you want to come up with a bunch of arbitrary rules for how your club should run and then argue about them with your spare time, bully for you. But don't try and act like there's real logic behind them.
Finding out fast where the disk space went is exactly the problem that's best solved with scripting. An admin who goes poking around the disk tree manually instead of launching a tool to help figure out what's wrong is a pretty poor one. Saying that path "twaddled around programming" tells me you've failed my interview. If you can't throw together a quick script to look for disk hogs in seconds using a UNIX tools pipeline, faster than you can click through even a few levels of directories with a standard UI, you have no place as an administrator in my world. Administrators who don't approach their work like a software developer, constantly building tools to improve their efficiency, they don't scale well enough to handle important servers.
You're making a pretty bold claim about open source in general from a small set of data. There's a perfectly valid way to evolve interfaces over time without having an explicit design up front. One way to do that is to iterate based on user feedback, and that's where projects like GNOME have failed the worst. That's their problem though, not the problem of all open source development. What I expect to happen with most of the bugs filed by this author is that they'll be marked "not a bug, you're doing it wrong" and that's the end of it. That persistent attitude is fundamentally why GNOME3 sucks, not because it was designed badly.
And so-called usability experts are part of the problem here too. For every Tufte there's a thousand mediocre designers, and from how that's worked out on commercial products they don't seem to listen to feedback either. The common trap desktop designers fall into is that if you aim for a desktop that is simple for a less technical person, a weak UI designer will cut out options and complicated features every time. The GNOME development team is famous for taking things that used to be customizable and removing both the less popular options and the configuration interface, thinking that simplification helps everyone. The idea that multiple workflows might be valuable because not everyone interacts with their computer exactly the same way seems lost on everyone doing that sort of work.
Open source tools should listen to their users, and weigh the habits of its most productive users just as heavily as the middle of the road ones. The people who get things done by developing programs for others are not to be scoffed at; they're part of why open source development has come so far. Believing in focus group and UI experts and flipping off feedback from outside users is leading to more spectacular failures each year lately. Windows Metro, Ubuntu's Unity, and GNOME 3 can all take their teams that ignore feedback from their advanced users and become irrelevant with that approach; they won't be missed. Apple seems heading the same way too, as they pull IOS elements into their desktop that nobody asked for, in some misplaced idea that tablet and desktop UIs need to be similar.
Sub-pixel rendering is heavily covered by Microsoft Patents. Blame them, or the rest of the industry that's stalling innovation with software patents; Apple does the same thing. Sub-pixel rendering is math you graph, and the idea that it's patentable is ridiculous. But since it is a real problem, free software can either avoid the major patents or risk getting pulled into a patent war that wastes a lot of money. Right now RedHat is avoiding them.
There is a whole section to that article describing why Steve Gibson's piece on this subject was worthless. You have to specifically attack the claims of the specific patent with prior art to kill it off, not just reference something that kinda sorta did something similar before.
And if you run all of your servers on VMs, it can be easy to roll back to a state where you're ready to do the SQL/Exchange setup with the time limit again. The only that has made my toying with Windows systems tolerable is being able to torpedo them and go back to a nice known state I saved a snapshot of.
Some eval software is smart enough to personally identify your hardware and generate a demo key based on it. If you ask for a second one, you won't get one for that hardware. The things used to collect that personally identifiable info are also easier to change on a VM install too. I have gotten around nagware that used the MAC address as a unique key for who has a demo license by just changing the MAC address on the VM. On Windows, knowing how you can modify a server without actually losing its activation is a real-world job skill too; it's not just cheapskate knowledge.
And by MS cloud, I mean a non user serviceable cloud run by Jeffrey Snover level powershelling autobots
Those are actually Decepticons.
The idea of becoming serious about Hyper-V is worth considering. Knowing a lot about virtualization is an overlapping skill set with considerable value of its own. It may be too much to chew off at once though. If the positions someone has their eye on involve Exchange and SQL, it's quite reasonable to gain basic skills at setting up virtual test servers and then moving onto those things. You can easily get lost in virtual systems for a long time, but that alone is hard to turn into a useful career path. A virtualization expert who is also a fair DBA is not going to be considered a skilled DBA by anyone, whereas a skilled DBA who knows a bit about virtualization can easily get a job.
I can usefully interview for sysadmins with a single question: "if you were paged that a [type of server used at the company] system is out of disk space, what would you do?" There's no right or wrong answer, but more experienced people will normally include a long list of things they've run into when that exact situation hit in previous work. Great answers include details on how to write a shell/Perl/Python program looking for common disk hogs. Bad ones discuss how to click on icons to check disk space.
In theory I can be fooled here by someone who just studied the topic deeply enough. But anyone who's done enough of that to rattle off a good sized list is someone likely to pick things up on the job too. And that's the most valuable skill of all.
The normal range for computer consulting companies is to charge 3 to 5X as much as the consultant is being paid. You might find an extremely lean one that operates at only 2X the consultant rates, especially if they are paying the consultant at 1099 rates (without withholding) rather than W2 ones. But having been on both sides of this for a while it's hard to be that generous to the consultants at most companies.
If the company is helping find leads and paying you sometimes when you'd otherwise be idle, all of this is quite reasonable. The main time I have found that overhead rate to be unfair to the consultant is when you're being pushed to work for a consulting company by the client, usually to keep their paperwork to a minimum. $BIG_CLIENT often has a contract with $TEMP_FIRM so that they only have one staffing company for consulting work. It's common in that position to discover $BIG_CLIENT advertising for positions, but requiring that you go through $TEMP_FIRM anyway in order to do work for them. And when the job is over, you're out. In that situation, it's reasonable to say $TEMP_FIRM doesn't deserve so much of your rate. Typically you have minimal negotiating power there though, because the only other option is to walk away from the work altogether.
Most manufacturers outside of the German cars are using systems developed by KeeLoq, so a vulnerability in that would impact a large number of vehicles. Parts of the encryption method have been attacked by researchers, with papers like How To Steal Cars. Some of these papers point out that the exact security mechanisms used by manufacturers on top of KeyLoq's hardware are not public, so turning the theoretical hacks into a working device is still hard even with these issues identified. Based on that FAQ, KeeLoq itself seems secure against anything but very knowledgeable attackers with significant resources--they're quoting months of work to find a real-world vulnerability. However, we can't be sure that a specific implementation of the security approach wasn't weakened by a manufacturer mistake. I wouldn't place a large bet on that though. Someone like a car manufacturer wants to be able to say they passed the risk to someone expert in this area. If they start customizing things to add back doors, they're going to lose any ability to blame KeeLoq if there's a nasty vulnerability.
The Tron arcade game was great though, also released in 1982. And after the terrible ET game, the early arcade games based on Star Wars and Star Trek from 1983 are all great fun to play. Not all of the home games based on movies are bad either. The Atari 2600 "Star Wars: The Empire Strikes Back" was decent.
I've corporate partners who rely heavily on gitbub.com
gitbub is the best there is at what they do, but what they do best isn't very nice.
If you are too dumb to know what type of PLC is implied by the context, the moron arrow is pointing at you here.
Yeah, I was just blowing dust out of a not easily replaced original IBM PC from 1982 at a manufacturing site last week, and I sure wouldn't call even that antique.
Serial ports are a pretty easy thing to deal with. In PC land it's stuff on old ISA cards that are the real nightmare. One of those is what's keeping that PC alive, and we can't even replace the system with a newer model because the software is only timed right at 4.77Mhz. I'm just glad I don't have any MCA bus hardware to worry about anymore.
Most of my computer interfacing work crosses over into analog signals, and I'm not always in the mood to wire up circuitry to make a Pi talk to them. And some days I don't want two boards talking to one another via some interface I maintain; I'd like to just have one board to deal with and move on. That's the mindset the UDOO is targeting.
The cool part about the Raspberry Pi is that it runs Linux. Its ability to interface with non computing hardware could be better.
The cool part about the Arduino is its analog and digital I/O interfaces. It has standard connectors for that purpose, beaten into useful form via a lot of people over the years, and there's even a good sized industry providing parts that plug into them. I can wander to my local Microcenter and get all sorts of Arduino parts nowadays.
The combination of the two, running Linux but with the Arduino interfaces, can cost more than both chips combined and still be worthwhile. That's what the UDOO is trying to do. If your goal is to have a generic system that can do all sorts of hacking, this is a possibility for such a device. Maybe the price will even come down over time to have less of a premium.
Related tangent: if you beat "Injustice: Gods Among Us", along with the credits for the graphics engine, physics engine, etc., at the very end you'll find the very viral and unusual OpenSSL license. Even Batman has to yield to weird software licenses!
Skills for game development are fun, but the at best 1% of the software development market they represent is not something a budding programmer should worry about too much.
Getting a CS degree involves a number of things that aren't just software development. Part of the reason degrees are considered valuable is because they prove people are willing to stick to the end of a project even if there are parts that are difficult for them. Almost everyone has something in a solid degree program that's hard for them. I breezed through math but struggled with chemistry. Sucked it up and worked through the parts that didn't come easy, because that's part of what degree programs are supposed to be about.
Your case then is that because some code is unreadable, obfuscated code might be just as useful as the original. That's possible, but you're arguing about an edge case. When someone is providing source code for a program in order to make it free, they should provide the same version of that code that development is done against, period. In some cases that code will be unreadable, and the maintainer has to spend a lot of time to change it too. But in many much more common situations, the code is much easier to read and work with in its original form, and these minimization/obfuscation steps make it harder to read or use.
Switching to OpenDocument won't make format incompatibilities go away; it will probably make them worse. The page rendering in OpenOffice is not the same as Microsoft Office, and both suites can change formatting between versions. Formatting on Linux and Windows isn't quite the same either, because of subtle font changes as a start. If you want formatting that is relatively stable, you can't use an Office-style tool at all. They are just not well suited for the job.
Even if you did have a tool that never screwed things up, I am confident you'll still find users who break documents by having no idea how formatting works. I've lost track of how many documents I've had to fix because the user did indenting with a hard carriage return and hitting space a few times. And then there's people who format tables by putting spaces between each column .