Seriously, the whole idea sounds like something the Morons would've come up with. To make a profit you have to sell something. But if you can't manufacture it, what product do you have to sell? What good are your designers if you've got nobody to turn your design into an actual product? What good are your retail stores if you don't have an actual product to put on their shelves? And if you outsource, what do you do when your manufacturing partners realize they've got you over a barrel and start demanding premium prices?
Being a plumber isn't a glamorous job. It means dealing with the dirty, stinky messes most people don't want to deal with. But it's got an upside: you'll never lack for work because everybody needs a plumber sooner or later and there's a lot more "everybodies" out there than there are plumbers. Most customers, after the first attempt or two at haggling and calling around about rates, will figure out that they're not in a strong bargaining position here. And the ones that don't? Well, they're ankle-deep in sewage but unlike you they're not getting paid for it.
My personal site's home page? Fairly large, 18k of which 11k is images. I mean, it's a home page not an image gallery or something like that where you expect a lot of large content.
I've seen some of those sites with large pages, and mostly I hate visiting them. The loading makes them feel like I'm wading through molasses, and the amount of stuff they're loading and the complexity of the scripts means more and more glitches and things that break when the network isn't perfect or they didn't expect the exact combination of things I've got at the moment. The pages come across as not being able to stay out of their own way, and more and more often they actually get in the way of my seeing what I came to the page for. There's merchants I've actually walked away from even though they had the product I wanted and had the best price on it simply because I couldn't get their pages to work well enough to get to the product page let alone order it. And I'm a techie who knows how to tweak the browser to make pages work when they don't want to, I shudder to think what it's like for someone who isn't a techie and is afraid to touch the security settings.
once you use GPLed code, you have no "freedom" what to do with your own code
This is false. You have every right to do whatever you want with your code. Your problem stems from the fact that the GPL'd parts? Aren't your code. You don't want the freedom to do whatever you want with your code, you want the freedom to do whatever you want with someone else's code and you're annoyed that they won't give it to you for free.
If the GPL'd code is such a minor portion it should be easy enough to not use it, or to go to the owner and negotiate a non-GPL license to it (most authors of GPL'd software aren't morally opposed to giving you a conventional commercial license if you're willing to pay for it).
I don't agree with those definitions. What you're calling selfless we've long had a term for: patsy. Schmuck. Gullible fool. Your definition of "selfless" is to put a lot of work into something, then stand by while someone else makes money off your work without giving you anything in return. Now, I'm willing to put work into things without getting anything in return, but it's usually the traditional kind of charity work where the person I'm helping is not running a for-profit business based on the work I'm doing for them. "I'm willing to mow your yard for free, because you've got a bad back and it's hard for you to do it. But if you want to start hiring my services out to other people and charging them money for me to mow their yards, either expect to start paying me a share or expect a lot of angry customers when I don't show up. Oh, and your yard? Not getting mowed for free anymore either.". I'm sure a lot of commercial enterprises would really like it if I did work for them for free and they could collect all the money, but I'm under no obligation to go along with that just because it's convenient for them.
If you want a more eloquent discussion of this, to talk to Terry Pratchett about his speaking fees.
Well, USERS won't be distributing copies of my code, so they aren't affected by the license. Only people including my code in their own works and distributing copies of those works (ie. programmers or the companies who employ them) need a copyright license because they're the only ones doing something that might reasonably infringe my copyright. Remember: you don't need a copyright license to use the code, because you're not doing anything that USC Title 17 (specifically section 117(a)) doesn't already grant you a legal right to do without a license. I'm perfectly fine with people doing things that don't infringe my copyright, it's when they want the rights only I have under copyright without complying with my terms for giving them those rights that I get annoyed with them.
The idea about GPL is great - make sure code stays open.
To me it's more a matter of "Make sure people don't go lifting my code and using it for their own commercial benefit (read: profit) without giving something back.". They can give back by making their own contributions to the code available to everyone on the same terms my code was made available to them under, or they can give back by coming to me and paying money for a regular commercial license to the code. But if they expect to get my code for free, no strings attached? Well, they aren't giving their product away for free, no strings attached, are they?
Example are the BSD unices that complain how they cannot use GPL'd drivers and other code, whereas the 'linux/gnu team' can happily borrow code from them. That's up to the very GPL license to fix.
Why should the GPL fix anything here? It's not the GPL side that has the problem. And I'd argue that it's not the BSD side that has the problem either. After all, they're the ones who decided on a license that allows this situation. They're the ones who consider that license better than the GPL. And now they're complaining that their license does exactly what they wanted it to do? If they didn't want that happening, they shouldn't've used a license whose intent was to allow exactly that to happen.
Yes I should, but how do I do that? If the CIO orders delivery by a specific date over my strenuous objection that it'll take 4 weeks longer than that, and orders that all the features he requests be in the project, and his superiors back him up, what precisely am I supposed to do as his subordinate? The only choice I have is to quit, which isn't going to protect my staff from anything because the CIO'll just replace me with someone else (preferably someone who won't argue with him so much).
That's the basic problem: as IT staff I can promise as much or as little as I want and it'll have no bearing on what the people in charge expect. That's one of the reasons I waffle about professional engineering laws for software development: it's one more burden to be sure, but at the same time if it follows the pattern of say civil engineering it also offers the protection that I can tell the CIO "No, as a professional engineer I'm telling you that the project will take 4 weeks longer than your timeframe to complete to the legally required standards of correctness." and he can't overrule me and he can't fire me or demote me or otherwise punish me. It'd also cull out the yes-men when it gets hammered home that, as with civil engineering, the law didn't recognize those "We disclaim all liability." EULAs and terms of service and did hold the developers personally financially liable right along with their employer for any damages resulting from bugs if best practices weren't followed. For all the downsides, you don't see many buildings falling down because someone decided meeting the delivery date was more important than letting the concrete in the foundations cure properly.
A: How many projects actually budget time and resources to developing documentation? Most of the time management insists on trimming that time off the project because it doesn't deliver any business features and will take longer than the actual development will (documentation is a time-consuming project in itself).
B: How often does management not want to allocate additional staff to essentially do nothing but learn someone else's job? The usual line I hear from management is that there's no return there, the additional person won't be doing anything that isn't already being done and they could be more useful doing something that isn't already being handled. And see A about documentation.
C: A good point, developers often aren't good at hand-off. But they aren't entirely to blame, see B and A for management's unwillingness to invest time and resources in the things you need to do a successful handoff. I also see a certain unwillingness to hold a BAU team responsible when the developers are right there and can just help with any problems that come up.
As with many things in IT, it comes down to the fact that the developers are not the ones with the authority to do these things. The authority and the responsibility rests with the managers and executives who make the decisions and set policy. As an "IT nerd" (read "techie, guy who's paid to make the little boxes with the blinkenlights do their thing") I'm often caught between the desire for good project discipline and the reality that management doesn't want good project discipline because it interferes with delivering the most features in the least amount of time (notice that I said "features", not "bug-free working software"). And I can't tell the CIO "No, you're not shaving 4 weeks off the project schedule. No, you're not assigning Joe to another project. No, you're not adding those 5 new requirements to the list without adding additional time to the schedule.". I'd love to, but I'm not his boss so I'm not the one giving him orders. And if he ignores what all the people under him are telling him, there's only one person responsible for the resulting trains-wreck. But his bosses won't hold him accountable for it, so it's no skin off his nose.
Naming convention: I've found that functional names are bad. EmailServer1 ends up getting a database added to it, and then e-mail gets moved off to another machine as part of an upgrade, and now the name no longer matches what the machine does. Bad.
I decide on a theme for names, or possibly a couple of themes, and assign machines random names based on those themes. If I need to assign functional names, I use CNAMEs or aliases to map the functional name to a real name. Then when EmailServer1 moves from "amethyst" to "diamond" I don't have to reconfigure machine names, I just change a CNAME record in the zonefile. When dealing with lots of machines it works well with naming conventions like "prefix followed by asset tag number", eg. "DT1057" or "SRV005".
Just don't pick themes that're NSFW or hard to type.
I have to agree. Google's seen how many headaches antitrust investigations and actions can be, and there's obvious logic behind keeping a major competitor around to point to. Google still profits off all the search referrals, so Firefox isn't costing them a lot of revenue, and having that second implementation means you a) have to code your site to work with both and b) have to make your browser correctly handle HTML/CSS/JS/etc. that's designed for both. That cross-compatibility's a selling point with devs, just ask anybody who's trying to make an IE6-specific site work well with IE 8 and later.
I tried to avoid looking at that kind of information when I had that kind of access. Firstly, I was usually too busy. I had plenty of authorized work to deal with, and if I had free time I had plenty of personal projects that didn't involve digging through the data. Second, it usually wasn't worth it. I've had to do plenty of company-ordered digging through people's accounts, and the interesting stuff just isn't worth digging through the weapons-grade "I did not need to know that..." material. And thirdly, it again wasn't worth it. I don't like to lie to conceal what I know, and for every useful item that directly affected me there were dozens of things that either weren't useful (I already knew my manager made twice what I did, knowing he makes exactly 2.13x as much... pfffft) or didn't affect me. It was easier overall if I honestly didn't know those things in the first place.
The dirty little secret is that most of the time everyone knows who's doing the unauthorized snooping. But management won't order an investigation because they're under the delusion that what they don't officially know about can't hurt the company. And besides the inevitable need to bleach their brains afterwards, all the front-line admins know that if they go initiating an investigation management will come down on them if they find anything. Even if the investigation was fully justified. Whatever it is needs to be pretty major to be worth the drama, angst and pain that'll result. And I don't see management's attitudes changing any time soon.
And that's one of the reasons things like sash exist. There's a long-standing tradition of trying to pare down/sbin (and/usr/sbin) to the absolute minimum number of items. The fewer things you need to depend on working, the easier it is to deal with the world blowing up.
Most people get to gloss all this over, because when the world blows up they just call the sysadmin and tell them to fix it. The sysadmin doesn't get that luxury.
The problem here though is that the whole reason for the logs being plain text is that the time you most need to be able to read the logs is exactly when things are broken, most services won't start because of the breakage, and your special tools may not be working because most of the system just isn't there. With plain text files, if you can boot into the single-user maintenance shell (not even single-user mode, literally running the shell as PID 1) and get the filesystem the logs are on mounted, you can read the logs and see what happened. With a more complicated system you end up in a catch-22 where you need to fix the breakage to get the tools working to find out what you need to fix to get the tools working.
This is, BTW, why/sbin exists separate from/bin. You couldn't always guarantee that libc was OK, so/sbin had statically-linked copies of critical tools that you could use to fix the system after something had trashed the critical system libraries.
That's one of the advantages of Linux: RedHat can go their own way without needing the rest of us to buy in, and without really messing things up for us. If they provide a reasonable API, it'll either be compatible with syslog with a simple library substitution or we'll quickly see a wrapper library that allows programs to use either syslog or Journal without needing code changes.
I think going to binary's a bad idea, myself. The fewer tools you need working to find out what the error is, the easier it is to debug and fix the problem. But let RedHat try this and see how it works, and then we can decide once we've got some real-world data to compare.
The construction workers were likely with firms already. This was just another job for them, it may have kept them from being laid off but any hiring this job created would've been strictly temporary and may not have been local (large outside construction firm brought in because they can do the work cheaper). Materials likewise probably weren't bought locally, the construction company probably has national supply contracts.
Not much revenue from truck drivers. They stop for lunch and that's about it.
Developers? They do their work on a computer. They probably don't access the data center directly at all, and if they do it's over the network. They can live anywhere that's got Internet connectivity. Why should they pack up and move to a small town in North Carolina?
The only way the local Apple store will bring in significant local revenue is if the locals already have jobs that pay well enough to afford to buy lots of Apple products. And if that's the case then they wouldn't be worried about needing to create more jobs in the area.
The proposed solution makes it easier to identify invalid certificates after a compromise is known. It doesn't do anything to stop the compromise, because the compromised certificates were issued correctly by the CA just like every valid certificate.
The problem is that the CAs aren't completely trustworthy and aren't completely impervious to attack, and never will be. Any solution needs to permit a compromised CA's root certificates to be revoked without instantly invalidating huge swathes of issued certificates that weren't part of the compromise. I don't see any way of doing that that doesn't involve changing the basic approach from one of "a single CA issues a specific certificate" to "one or more CAs certify the authenticity and validity of a certificate'. In short, CAs cease being the sole issuers of documents and become the equivalent of notaries public certifying that the person who created the certificate is really who the certificate says they are.
No. All letting it free would do is to let an exploit into the wild with no patch.
Yes, it's exactly like that. Let's see now, when a company says "It's a theoretical vulnerability, there's no exploit for it currently in the wild, so the severity is "low".", what usually happens? Lo and behold, we find there is in fact an exploit in the wild, usually within a few days of the company's claim, and it usually turns out the exploit's been in use for months to years. And we usually find this out when victims, now knowing what to look for, find out they've been compromised and go public with it.
You'd better pray it's not like that, or we'll be finding out that the bad guys already had it will be a continental-scale epidemic.
If it was done, the information's out there. If the work's already been presented at a conference, it's pretty much a guarantee the black-hats have it. And if they don't already, they know it can be done and they've got enough clues to know where to go looking. So the question isn't whether we give the black-hats the information or not, it's whether only the black-hats get the information or whether the white-hats get it too. I'd rather have the information circulated so doctors and public health systems know what to look for and how to treat it when it shows up.
Pretty much, yeah. The first thing I thought when I saw the rewrite rule you need to have to allow the vulnerability is "Hey, that's not right! There ought to be a slash before the $1 there, if you don't want unexpected weirdness in the incoming URL to mess things up.". I can see why a naive admin might want to do that, but it's dangerous and to be avoided because it's making a lot of assumptions about people playing by the rules that you just can't make (at least not on a publicly-accessible server, and you shouldn't be making them even on an internal server).
This ought to be patched just to be safe, but if you're vulnerable to it you've got bigger potential problems with your configuration.
There's commercial pirates who make money off pirated games/software. But, as with movies and music, they aren't the ones putting it up for download. They're the ones stamping exact copies of the discs on cheap Asian production lines, duplicating the case art, and selling cheap physical copies into the regular distribution stream. And with multiple tiers of distribution the retailer may not even be aware of it, they may be getting their product through a distributor whose buyer found a really great price from a new wholesaler.
It isn't limited to media, either. We've had cases around here of stuff at big supermarket and retail chains turning out to be counterfeit. It slipped through because it was coming through the store's normal distributor and the price was low enough to be something they couldn't pass up but not so low that it was "too good to be true".
Of course charging for something diminishes it's value. Just look at open source.
Except that DRM isn't in itself about charging for something. I don't mind paying for a product. I mind very much paying for a product and then having to jump through hoops to get it delivered to me. And then finding that some software that's not needed to use my product but required anyway before the product will allow itself to be used causes problems with other software on my machine. And then finding out that I'm not allowed to use my product even though I've paid for it, just because I want to use it somewhere other than the machine I was using when I paid for it. Or that it won't allow itself to be displayed because of the particular I/O channel I want to use (even though, remember, I paid for it and I'm not trying to make illegal copies of it). And of course wondering whether I'll be able to keep using it when the company I bought it from goes out of business or decides to change their DRM scheme and the DRM servers the product wants to talk to aren't there anymore (through no fault of mine), or if my computer breaks and I have to replace it and reload everything and of course I can't reload the product because I only got the one copy and I'm not allowed to make backups (more copies).
Meanwhile, the illegal copy will play anywhere I want to play it. It'll keep playing as long as I have a copy, no matter what happens to anybody else's servers. I can back it up so I don't have to worry about losing my hard drive's contents. And I don't have to worry nearly as much about software conflicts.
"The universe is probably littered with the one-planet graves of cultures which made the sensible economic decision that thereâ(TM)s no good reason to go into space â" each discovered, studied, and remembered by the ones who made the irrational decision."
When I set up an AP I'm broadcasting the SSID to everyone in range. I know this when I set it up. It's pretty much a physical requirement of wireless that you broadcast at least it's presence. Even secured point-to-point links broadcast a signal that any receiver in range can pick up. If I care that people know my AP exists in a particular spot, I shouldn't be using a broadcast technology!
NB: getting on my wireless won't help you much. Most of the computers in my home are on the wired LAN for security and the wireless subnet does not have access to the wired LAN, only the Internet. I put my trust not in data links any joker with a Pringles-can antenna can access.
The IRS website is... incomplete. You'd want to refer to the actual IRS regulations, which have provisions for just such orders as that. The judge will order the custodial parent to file IRS Form 8332, end of story.
This is why you hire a lawyer.
Affordable replacement for something paid for
on
The F-35 Story
·
· Score: 3, Insightful
The JSF's biggest problem: it's a replacement for things the military already owns. No matter how much more cost-effective it might be, the planes it's intended to replace have already been paid for. The spare parts are already bought and paid for and in the warehouse. The pilots and ground crews are already trained. And everybody else uses those same planes too so wherever we go we can be assured of finding support facilities that'll accommodate the existing planes. No matter how affordable the JSF is, it's still going to cost more to bring into service than it'll cost to keep the existing planes flying.
And it isn't bringing anything to the table that the existing planes don't do. Sure it'll do in one package what you'd need several other models of aircraft to do, but it's not so incredibly more effective that you'd need fewer total planes and you still have to buy all new planes and spares and train crews on it. If you're tight on cash, you stick with what you've already got.
Slashdot Mirror
Seriously, the whole idea sounds like something the Morons would've come up with. To make a profit you have to sell something. But if you can't manufacture it, what product do you have to sell? What good are your designers if you've got nobody to turn your design into an actual product? What good are your retail stores if you don't have an actual product to put on their shelves? And if you outsource, what do you do when your manufacturing partners realize they've got you over a barrel and start demanding premium prices?
Being a plumber isn't a glamorous job. It means dealing with the dirty, stinky messes most people don't want to deal with. But it's got an upside: you'll never lack for work because everybody needs a plumber sooner or later and there's a lot more "everybodies" out there than there are plumbers. Most customers, after the first attempt or two at haggling and calling around about rates, will figure out that they're not in a strong bargaining position here. And the ones that don't? Well, they're ankle-deep in sewage but unlike you they're not getting paid for it.
My personal site's home page? Fairly large, 18k of which 11k is images. I mean, it's a home page not an image gallery or something like that where you expect a lot of large content.
I've seen some of those sites with large pages, and mostly I hate visiting them. The loading makes them feel like I'm wading through molasses, and the amount of stuff they're loading and the complexity of the scripts means more and more glitches and things that break when the network isn't perfect or they didn't expect the exact combination of things I've got at the moment. The pages come across as not being able to stay out of their own way, and more and more often they actually get in the way of my seeing what I came to the page for. There's merchants I've actually walked away from even though they had the product I wanted and had the best price on it simply because I couldn't get their pages to work well enough to get to the product page let alone order it. And I'm a techie who knows how to tweak the browser to make pages work when they don't want to, I shudder to think what it's like for someone who isn't a techie and is afraid to touch the security settings.
once you use GPLed code, you have no "freedom" what to do with your own code
This is false. You have every right to do whatever you want with your code. Your problem stems from the fact that the GPL'd parts? Aren't your code. You don't want the freedom to do whatever you want with your code, you want the freedom to do whatever you want with someone else's code and you're annoyed that they won't give it to you for free.
If the GPL'd code is such a minor portion it should be easy enough to not use it, or to go to the owner and negotiate a non-GPL license to it (most authors of GPL'd software aren't morally opposed to giving you a conventional commercial license if you're willing to pay for it).
I don't agree with those definitions. What you're calling selfless we've long had a term for: patsy. Schmuck. Gullible fool. Your definition of "selfless" is to put a lot of work into something, then stand by while someone else makes money off your work without giving you anything in return. Now, I'm willing to put work into things without getting anything in return, but it's usually the traditional kind of charity work where the person I'm helping is not running a for-profit business based on the work I'm doing for them. "I'm willing to mow your yard for free, because you've got a bad back and it's hard for you to do it. But if you want to start hiring my services out to other people and charging them money for me to mow their yards, either expect to start paying me a share or expect a lot of angry customers when I don't show up. Oh, and your yard? Not getting mowed for free anymore either.". I'm sure a lot of commercial enterprises would really like it if I did work for them for free and they could collect all the money, but I'm under no obligation to go along with that just because it's convenient for them.
If you want a more eloquent discussion of this, to talk to Terry Pratchett about his speaking fees.
Well, USERS won't be distributing copies of my code, so they aren't affected by the license. Only people including my code in their own works and distributing copies of those works (ie. programmers or the companies who employ them) need a copyright license because they're the only ones doing something that might reasonably infringe my copyright. Remember: you don't need a copyright license to use the code, because you're not doing anything that USC Title 17 (specifically section 117(a)) doesn't already grant you a legal right to do without a license. I'm perfectly fine with people doing things that don't infringe my copyright, it's when they want the rights only I have under copyright without complying with my terms for giving them those rights that I get annoyed with them.
The idea about GPL is great - make sure code stays open.
To me it's more a matter of "Make sure people don't go lifting my code and using it for their own commercial benefit (read: profit) without giving something back.". They can give back by making their own contributions to the code available to everyone on the same terms my code was made available to them under, or they can give back by coming to me and paying money for a regular commercial license to the code. But if they expect to get my code for free, no strings attached? Well, they aren't giving their product away for free, no strings attached, are they?
Example are the BSD unices that complain how they cannot use GPL'd drivers and other code, whereas the 'linux/gnu team' can happily borrow code from them. That's up to the very GPL license to fix.
Why should the GPL fix anything here? It's not the GPL side that has the problem. And I'd argue that it's not the BSD side that has the problem either. After all, they're the ones who decided on a license that allows this situation. They're the ones who consider that license better than the GPL. And now they're complaining that their license does exactly what they wanted it to do? If they didn't want that happening, they shouldn't've used a license whose intent was to allow exactly that to happen.
Yes I should, but how do I do that? If the CIO orders delivery by a specific date over my strenuous objection that it'll take 4 weeks longer than that, and orders that all the features he requests be in the project, and his superiors back him up, what precisely am I supposed to do as his subordinate? The only choice I have is to quit, which isn't going to protect my staff from anything because the CIO'll just replace me with someone else (preferably someone who won't argue with him so much).
That's the basic problem: as IT staff I can promise as much or as little as I want and it'll have no bearing on what the people in charge expect. That's one of the reasons I waffle about professional engineering laws for software development: it's one more burden to be sure, but at the same time if it follows the pattern of say civil engineering it also offers the protection that I can tell the CIO "No, as a professional engineer I'm telling you that the project will take 4 weeks longer than your timeframe to complete to the legally required standards of correctness." and he can't overrule me and he can't fire me or demote me or otherwise punish me. It'd also cull out the yes-men when it gets hammered home that, as with civil engineering, the law didn't recognize those "We disclaim all liability." EULAs and terms of service and did hold the developers personally financially liable right along with their employer for any damages resulting from bugs if best practices weren't followed. For all the downsides, you don't see many buildings falling down because someone decided meeting the delivery date was more important than letting the concrete in the foundations cure properly.
My response is:
As with many things in IT, it comes down to the fact that the developers are not the ones with the authority to do these things. The authority and the responsibility rests with the managers and executives who make the decisions and set policy. As an "IT nerd" (read "techie, guy who's paid to make the little boxes with the blinkenlights do their thing") I'm often caught between the desire for good project discipline and the reality that management doesn't want good project discipline because it interferes with delivering the most features in the least amount of time (notice that I said "features", not "bug-free working software"). And I can't tell the CIO "No, you're not shaving 4 weeks off the project schedule. No, you're not assigning Joe to another project. No, you're not adding those 5 new requirements to the list without adding additional time to the schedule.". I'd love to, but I'm not his boss so I'm not the one giving him orders. And if he ignores what all the people under him are telling him, there's only one person responsible for the resulting trains-wreck. But his bosses won't hold him accountable for it, so it's no skin off his nose.
Naming convention: I've found that functional names are bad. EmailServer1 ends up getting a database added to it, and then e-mail gets moved off to another machine as part of an upgrade, and now the name no longer matches what the machine does. Bad.
I decide on a theme for names, or possibly a couple of themes, and assign machines random names based on those themes. If I need to assign functional names, I use CNAMEs or aliases to map the functional name to a real name. Then when EmailServer1 moves from "amethyst" to "diamond" I don't have to reconfigure machine names, I just change a CNAME record in the zonefile. When dealing with lots of machines it works well with naming conventions like "prefix followed by asset tag number", eg. "DT1057" or "SRV005".
Just don't pick themes that're NSFW or hard to type.
I have to agree. Google's seen how many headaches antitrust investigations and actions can be, and there's obvious logic behind keeping a major competitor around to point to. Google still profits off all the search referrals, so Firefox isn't costing them a lot of revenue, and having that second implementation means you a) have to code your site to work with both and b) have to make your browser correctly handle HTML/CSS/JS/etc. that's designed for both. That cross-compatibility's a selling point with devs, just ask anybody who's trying to make an IE6-specific site work well with IE 8 and later.
I tried to avoid looking at that kind of information when I had that kind of access. Firstly, I was usually too busy. I had plenty of authorized work to deal with, and if I had free time I had plenty of personal projects that didn't involve digging through the data. Second, it usually wasn't worth it. I've had to do plenty of company-ordered digging through people's accounts, and the interesting stuff just isn't worth digging through the weapons-grade "I did not need to know that..." material. And thirdly, it again wasn't worth it. I don't like to lie to conceal what I know, and for every useful item that directly affected me there were dozens of things that either weren't useful (I already knew my manager made twice what I did, knowing he makes exactly 2.13x as much... pfffft) or didn't affect me. It was easier overall if I honestly didn't know those things in the first place.
The dirty little secret is that most of the time everyone knows who's doing the unauthorized snooping. But management won't order an investigation because they're under the delusion that what they don't officially know about can't hurt the company. And besides the inevitable need to bleach their brains afterwards, all the front-line admins know that if they go initiating an investigation management will come down on them if they find anything. Even if the investigation was fully justified. Whatever it is needs to be pretty major to be worth the drama, angst and pain that'll result. And I don't see management's attitudes changing any time soon.
And that's one of the reasons things like sash exist. There's a long-standing tradition of trying to pare down /sbin (and /usr/sbin) to the absolute minimum number of items. The fewer things you need to depend on working, the easier it is to deal with the world blowing up.
Most people get to gloss all this over, because when the world blows up they just call the sysadmin and tell them to fix it. The sysadmin doesn't get that luxury.
The problem here though is that the whole reason for the logs being plain text is that the time you most need to be able to read the logs is exactly when things are broken, most services won't start because of the breakage, and your special tools may not be working because most of the system just isn't there. With plain text files, if you can boot into the single-user maintenance shell (not even single-user mode, literally running the shell as PID 1) and get the filesystem the logs are on mounted, you can read the logs and see what happened. With a more complicated system you end up in a catch-22 where you need to fix the breakage to get the tools working to find out what you need to fix to get the tools working.
This is, BTW, why /sbin exists separate from /bin. You couldn't always guarantee that libc was OK, so /sbin had statically-linked copies of critical tools that you could use to fix the system after something had trashed the critical system libraries.
That's one of the advantages of Linux: RedHat can go their own way without needing the rest of us to buy in, and without really messing things up for us. If they provide a reasonable API, it'll either be compatible with syslog with a simple library substitution or we'll quickly see a wrapper library that allows programs to use either syslog or Journal without needing code changes.
I think going to binary's a bad idea, myself. The fewer tools you need working to find out what the error is, the easier it is to debug and fix the problem. But let RedHat try this and see how it works, and then we can decide once we've got some real-world data to compare.
The proposed solution makes it easier to identify invalid certificates after a compromise is known. It doesn't do anything to stop the compromise, because the compromised certificates were issued correctly by the CA just like every valid certificate.
The problem is that the CAs aren't completely trustworthy and aren't completely impervious to attack, and never will be. Any solution needs to permit a compromised CA's root certificates to be revoked without instantly invalidating huge swathes of issued certificates that weren't part of the compromise. I don't see any way of doing that that doesn't involve changing the basic approach from one of "a single CA issues a specific certificate" to "one or more CAs certify the authenticity and validity of a certificate'. In short, CAs cease being the sole issuers of documents and become the equivalent of notaries public certifying that the person who created the certificate is really who the certificate says they are.
No. All letting it free would do is to let an exploit into the wild with no patch.
Yes, it's exactly like that. Let's see now, when a company says "It's a theoretical vulnerability, there's no exploit for it currently in the wild, so the severity is "low".", what usually happens? Lo and behold, we find there is in fact an exploit in the wild, usually within a few days of the company's claim, and it usually turns out the exploit's been in use for months to years. And we usually find this out when victims, now knowing what to look for, find out they've been compromised and go public with it.
You'd better pray it's not like that, or we'll be finding out that the bad guys already had it will be a continental-scale epidemic.
If it was done, the information's out there. If the work's already been presented at a conference, it's pretty much a guarantee the black-hats have it. And if they don't already, they know it can be done and they've got enough clues to know where to go looking. So the question isn't whether we give the black-hats the information or not, it's whether only the black-hats get the information or whether the white-hats get it too. I'd rather have the information circulated so doctors and public health systems know what to look for and how to treat it when it shows up.
Pretty much, yeah. The first thing I thought when I saw the rewrite rule you need to have to allow the vulnerability is "Hey, that's not right! There ought to be a slash before the $1 there, if you don't want unexpected weirdness in the incoming URL to mess things up.". I can see why a naive admin might want to do that, but it's dangerous and to be avoided because it's making a lot of assumptions about people playing by the rules that you just can't make (at least not on a publicly-accessible server, and you shouldn't be making them even on an internal server).
This ought to be patched just to be safe, but if you're vulnerable to it you've got bigger potential problems with your configuration.
There's commercial pirates who make money off pirated games/software. But, as with movies and music, they aren't the ones putting it up for download. They're the ones stamping exact copies of the discs on cheap Asian production lines, duplicating the case art, and selling cheap physical copies into the regular distribution stream. And with multiple tiers of distribution the retailer may not even be aware of it, they may be getting their product through a distributor whose buyer found a really great price from a new wholesaler.
It isn't limited to media, either. We've had cases around here of stuff at big supermarket and retail chains turning out to be counterfeit. It slipped through because it was coming through the store's normal distributor and the price was low enough to be something they couldn't pass up but not so low that it was "too good to be true".
Of course charging for something diminishes it's value. Just look at open source.
Except that DRM isn't in itself about charging for something. I don't mind paying for a product. I mind very much paying for a product and then having to jump through hoops to get it delivered to me. And then finding that some software that's not needed to use my product but required anyway before the product will allow itself to be used causes problems with other software on my machine. And then finding out that I'm not allowed to use my product even though I've paid for it, just because I want to use it somewhere other than the machine I was using when I paid for it. Or that it won't allow itself to be displayed because of the particular I/O channel I want to use (even though, remember, I paid for it and I'm not trying to make illegal copies of it). And of course wondering whether I'll be able to keep using it when the company I bought it from goes out of business or decides to change their DRM scheme and the DRM servers the product wants to talk to aren't there anymore (through no fault of mine), or if my computer breaks and I have to replace it and reload everything and of course I can't reload the product because I only got the one copy and I'm not allowed to make backups (more copies).
Meanwhile, the illegal copy will play anywhere I want to play it. It'll keep playing as long as I have a copy, no matter what happens to anybody else's servers. I can back it up so I don't have to worry about losing my hard drive's contents. And I don't have to worry nearly as much about software conflicts.
Counterpoint:
"The universe is probably littered with the one-planet graves of cultures which made the sensible economic decision that thereâ(TM)s no good reason to go into space â" each discovered, studied, and remembered by the ones who made the irrational decision."
When I set up an AP I'm broadcasting the SSID to everyone in range. I know this when I set it up. It's pretty much a physical requirement of wireless that you broadcast at least it's presence. Even secured point-to-point links broadcast a signal that any receiver in range can pick up. If I care that people know my AP exists in a particular spot, I shouldn't be using a broadcast technology!
NB: getting on my wireless won't help you much. Most of the computers in my home are on the wired LAN for security and the wireless subnet does not have access to the wired LAN, only the Internet. I put my trust not in data links any joker with a Pringles-can antenna can access.
The IRS website is... incomplete. You'd want to refer to the actual IRS regulations, which have provisions for just such orders as that. The judge will order the custodial parent to file IRS Form 8332, end of story.
This is why you hire a lawyer.
The JSF's biggest problem: it's a replacement for things the military already owns. No matter how much more cost-effective it might be, the planes it's intended to replace have already been paid for. The spare parts are already bought and paid for and in the warehouse. The pilots and ground crews are already trained. And everybody else uses those same planes too so wherever we go we can be assured of finding support facilities that'll accommodate the existing planes. No matter how affordable the JSF is, it's still going to cost more to bring into service than it'll cost to keep the existing planes flying.
And it isn't bringing anything to the table that the existing planes don't do. Sure it'll do in one package what you'd need several other models of aircraft to do, but it's not so incredibly more effective that you'd need fewer total planes and you still have to buy all new planes and spares and train crews on it. If you're tight on cash, you stick with what you've already got.