Funny, I deal with people who have degrees who don't understand that planning is important, and I myself who have no degree know exactly why planning is important. The degree doesn't get you this. Actually having a functioning brain gets you this.
I've dealt with lots of people who think because they have a degree in x that they know everything. That's a separate topic from the original question, but it goes back to the question of why you want the degree. Ten years ago I wanted the degree as an entrance into this field. I didn't get the degree for a variety of reasons, none relating to my ability. Now the degree won't mean a whole lot, compared to the experience I have.
Why do you want the degree? Do you want more money, better job security, to move to management? Are you unhappy enough with where you're going that you want to invest the time to do something else? Or do you just want it because you feel like you missed out because you didn't get it?
I'm in a similar position, but I like what I'm doing, and while more money is cool, there are better ways for me to do it than spending lots of time sitting in a class "learning" stuff I already know. I don't think I'm going to go back to school unless I'm switching careers.
Our courts finally figured out that French law didn't apply to an American company publishing on an American site. It seems our hope might be that the courts will decide that the treaty (and laws that are passed in compliance with it) cannot supercede the US constitution. Otherwise they've just done an end-run around the constitution. Which was probably their plan.
The most common form of language-mixing for me is using inlne assembly in C++ code. Obviously this isn't portable (unless I can #ifdef in a C++ version of the code for other architectures) but there have been several occasions where this is useful because portability isn't a concern. I don't want to write my entire application in assembly, but for raw number-crunching, hand-coding a tight routine using a good algorithm can be hard to beat. In this case, the cost of the context-switch is very low.
Other environments may be different. If you're building something that is essentially a shell script, then you're already calling various tools to do your work, be they written in C, Perl, or whatever. In this case, the shell is your "glue".
Back in the Windows world, plenty of projects use VB for their glue, and the gurus are left to build components using C++. Or web apps are built with ColdFusion, and middleware written by a different team using Java.
I think this kind of multi-language approach is more common when you have easily separatable tasks and the cost of using a different language is not large. (In the middleware example above, using Java instead of CF for your middleware might not be a big problem if the middleware is already running on a separate server and you're using SOAP or something similar to access your middleware's API.)
Certainly where I work we use different languages for our projects, but we're in a web environment where it's easier to build things this way.
The brief explains why the artists don't think it qualifies as a work for hire. Basically, it's because they don't receive any of the normal compensation one would get for a work for hire; they're not paid, they don't receive benefits, they just get a loan. They pay the expense of recording the album; they decide what goes into it. And they provide the legal references to back up their viewpoint. A contract that is direct contradiction to the law isn't necessarily valid, even if it's signed.
Their goal is to make sure that recordings are not considered works for hire. Currently the law is on their side. As a work for hire, if they terminate their contracts with the label they don't get to recover their copyright. This isn't about nullifying the contract; it's about what happens when the contract is terminated.
If more states hold out, stronger restrictions may end up being imposed anyway, and perhaps it will become clear to the DoJ that settling wasn't the right thing to do. (Stop laughing. Some of us would like to hang on to at least a shred of hope.)
Alternative to cookie: URL-rewriting and its flaws
on
EU May Outlaw Cookies
·
· Score: 3, Interesting
Ultimately there are too many applications that run over the web that have to have session identifiers. Sometimes it's so that it can identify returning visitors, sometimes it's so it can just track some current information (like your shopping cart). Somewhere, it's going to have to stick that session identifier in there.
You can put it in the cookie, but that means people who disable cookies on general principles can't use your site. Sort of a nuisance.
You can put in on the URL, but if you do that, you have to be aware that people may send URLs containing session identifiers to their friends by e-mail, or they might post them to a newsgroup, or better yet, they might just put up their own web site with a link with that ID in it. I've seen all three in sites I've worked on that use URL-rewriting.
Because we wanted to avoid cookies, we started checking referrers on inbound requests. Yes, of course referrer can be spoofed; that's not the issue. We simply wanted to catch casual sharing of URLs containing session identifiers. Any referrer that doesn't match the site of the actual request, or where the session ID is different than the one in the request, is rejected; a new session is established at that point. If the request was for an interior page that requires logging in first, the user then gets booted back to the site entrance or a login page.
It really depends on whether you want to go ahead and use cookies or not. I prefer not. Cookies certainly are not the only way to manage sessions.
On the otherhand, what Microsoft is doing is asking Mozilla what it can do, but simply saying "Your badge says Mozilla; go away."
Then it's MSN that is flawed, not the protocol.
I think the benefits of user-agent strings outweigh the disadvantages. Yes, some sites may elect to block you based on your user-agent strings. Fine; you provided the string, you can change it. In exchange, you get the ability of the server to work around known buggy clients; to serve up content that might break other user-agents; to collect usage statistics (knowing that it can be skewed). Of these, the second is the most important. I'm starting to use this to serve up different JavaScript based on the user-agent, because this reduces the bandwidth consumption by the client (it's not downloading code it won't use).
And in extreme cases, I can actually see a need to use this. Let's say you find a version of SSH which is critically flawed, such that it will compromise the encryption process and make your session essentially plaintext. The server recognizes your version and refuses to allow you to connect, telling you you must upgrade. That might actually be a good thing.
The problem here is that Microsoft used its monopoly power on the OS to leverage a near-monopoly on the browser (my last stats indicated about 85% of visitors were IE). Now they're using that near-monopoly, in concert with the rollout of Windows XP and all the services it has tied to MSN, to turn MSN into a monopoly-like site, one you have to deal with in order to do anything on the web. Sure, they say you can run all that lovely.NET stuff on any platform... but what they really mean is, any Microsoft platform: Windows + IE.
They're just tying it all together. The only surprising thing here is that they had the balls to go this far, not that they wanted to do it.
Re:What is a Good Mailing List for this Info?
on
Linux Kernel Bugs
·
· Score: 1
Red Hat Watch is a good list for being notified of patches. BugTraq is great if you want to know about the holes as they're discovered, which may be before the patch is announced.
Re:Difference between this and the IIS holes
on
Linux Kernel Bugs
·
· Score: 1
That depends on how your corporate environment is set up. I expect that plenty of corporations that use Linux on their servers still use Windows on the desktop, and actual logins to the servers is severely restricted. (After all, your typical office worker can barely handle a DOS prompt, let alone a UNIX shell.) So it's not good, but it's still not a remotely-exploitable root hole.
Of course all corporate networks should be reasonably segmented so that compromise in one doesn't automatically compromise the entire network, but few businesses are willing to set up their network that way, probably because they're not sufficiently paranoid.
Difference between this and the IIS holes
on
Linux Kernel Bugs
·
· Score: 1
While it's true that this is a nasty, bad root exploit... at least it's a LOCAL exploit. You have to already have local access to the machine in order to take advantage of it.
The IIS holes of late have been REMOTE exploits. Any half-wit script kiddie can take advantage of it.
This is a fair point. It's also worth noting that overflows in browsers (IE) would need tuning since there are so many different versions of key DLLs floating around for it.
However it's obvious that IIS is fairly consistent throughout the NT/2K server realm, given the number of systems infected by Code Red. So while it's not exactly monoculture, it's still fairly homogenous!
No, it's probably that you forgot to include space for the NUL character to terminate the string. You need char username[9]; and then you still be paranoid about checking the length.
Even if Linux gained market dominance, it wouldn't quite be the monoculture that Windows is. There are many distributions of Linux, which put important files in different places. This isn't insurmountable but it does make writing a worm capable of running rampant a wee bit harder.
Also, it's my experience that (for now) people who set up Linux to run on the net are a little bit more clueful than NT administrators. NT seems to encourage the idea that any moron can run it because it's point and click. This isn't true; it takes more work to effectively admin an NT box than a Linux box.
There have and will continue to be worms. Worms are most successful at any point of monoculture. (sendmail; bind; IIS) The solution, then, is not dominance... but diversity.
Not only that, but the absentee vote wasn't even counted in many states because there weren't enough of them to make a difference in the outcome of the electoral vote... but it would have made a big difference in the popular vote, which was very close.
We will never know who actually won the popular vote. To cotinue to say that Gore won the popular vote is like saying Gore won the election... so long as you don't count any of the states he lost in.
It's just the pipe out to the net is clogged, the CPU is 91% idle right now. I'm sorry it's not the world's fattest pipe, but it does handle normal traffic without problems. Bandwidth costs money, y'know? Keep trying and your requests may squeak through.
Anyone who wants to mirror the entire page, with the embedded graphics, is welcome to, to make the material more accessible. Steve updates this page from time to time, so don't expect your mirror to stay current forever.
Those of you who scoff and say you don't have time to implement good software are shooting yourselves in the foot.
Where I work, we've developed a lot of code. We re-use as much as we can. And because a lot of our code isn't simple/elegant/pretty, it takes us more time to re-use that code than it should. It's still faster than rewriting the code but it's nowhere near as effective as it could be.
So earlier this year I began pushing for a major project to refactor and clean up this code. Already the initial stages of this project (implemented by several programmers on our staff) have yielded huge gains in how quickly we can develop stuff. As we continue to clean and simplify, these gains increase.
This is real-world. We have deadlines just as impossible as anyone else. We're doing this effort so that we can meet these deadlines on more and more projects.
If you ever plan on using that code again, write it clean. You'll thank yourself later.
They might switch because of the bottom line, but then stick with it when they find out how stable it is. The point is, if you can get them to TRY it, you're 90% of the way there. Our NT servers go down all the time, can't handle huge volumes of e-mail, etc. but the free software boxen just keep running.
Well bully for you. I'm glad you're enjoying your no-spam status.
I tried exactly the same thing. I had a private e-mail address that I never used for Usenet, never posted to a web site, never gave to anyone except people I wanted to hear from. Since I run my own domain, I was able to make up a new e-mail address every time I had to give one out to an untrustworthy site registration. (And in some cases caught them giving my address to spammers.)
That all lasted until two people separately posted my private e-mail address to web pages they made. That's it. Just two pages. Since then, the amount of spam delivered to that address has skyrocketed; I now get 10-20 per day.
A week ago I investigated a spam mail forwarded from a friend who was concerned. It was a scam to extract credit card numbers from unwitting newbies, and the levels to which this PacBell DSL user went to hide their origins was amazing. Spammers too often use stolen credit card numbers to get new dial-up accounts, from which they spam open relays. Fixing SMTP will help, but not eliminate the problem. Spammers will keep trying because they're not paying anything.
Of course your Palm itself isn't secure, even if you lock it, since you can put it into a debugging state right from the password prompt...
Linux on PS2 demo'd at E3
on
PS2 As PC
·
· Score: 1
I saw it, I have photos. Linux (2.2 kernel) running on PS2, with X, with Netscape. Working. If you think the PS2 doesn't have enough RAM for this, you're wrong, it worked fine. They were also showing AOL running on this base, with the Linux part almost completely hidden.
The net appliance thing has always been a mixed bag. There are plenty of people for whom it's all they need; an easy box to check mail and surf the web. I think the PS2 running Linux, provided that Linux is hidden from view and the user is presented with a "dummy" sort of interface, could do quite well. But it's not in any way intended for the/. crowd.
Of course I'm not saying Sony would be any better than MS. But I think this could be a pretty good thing, overall.
Fractal images don't have infinite detail because computers can't render an infinite number of pixels or perform an infinite number of iterations. However, if either of those two feats could be accomplished, the graph of the equation would have an infinite frequency spectrum, infinite detail.
Slashdot Mirror
Funny, I deal with people who have degrees who don't understand that planning is important, and I myself who have no degree know exactly why planning is important. The degree doesn't get you this. Actually having a functioning brain gets you this.
I've dealt with lots of people who think because they have a degree in x that they know everything. That's a separate topic from the original question, but it goes back to the question of why you want the degree. Ten years ago I wanted the degree as an entrance into this field. I didn't get the degree for a variety of reasons, none relating to my ability. Now the degree won't mean a whole lot, compared to the experience I have.
Why do you want the degree? Do you want more money, better job security, to move to management? Are you unhappy enough with where you're going that you want to invest the time to do something else? Or do you just want it because you feel like you missed out because you didn't get it?
I'm in a similar position, but I like what I'm doing, and while more money is cool, there are better ways for me to do it than spending lots of time sitting in a class "learning" stuff I already know. I don't think I'm going to go back to school unless I'm switching careers.
Our courts finally figured out that French law didn't apply to an American company publishing on an American site. It seems our hope might be that the courts will decide that the treaty (and laws that are passed in compliance with it) cannot supercede the US constitution. Otherwise they've just done an end-run around the constitution. Which was probably their plan.
The most common form of language-mixing for me is using inlne assembly in C++ code. Obviously this isn't portable (unless I can #ifdef in a C++ version of the code for other architectures) but there have been several occasions where this is useful because portability isn't a concern. I don't want to write my entire application in assembly, but for raw number-crunching, hand-coding a tight routine using a good algorithm can be hard to beat. In this case, the cost of the context-switch is very low.
Other environments may be different. If you're building something that is essentially a shell script, then you're already calling various tools to do your work, be they written in C, Perl, or whatever. In this case, the shell is your "glue".
Back in the Windows world, plenty of projects use VB for their glue, and the gurus are left to build components using C++. Or web apps are built with ColdFusion, and middleware written by a different team using Java.
I think this kind of multi-language approach is more common when you have easily separatable tasks and the cost of using a different language is not large. (In the middleware example above, using Java instead of CF for your middleware might not be a big problem if the middleware is already running on a separate server and you're using SOAP or something similar to access your middleware's API.)
Certainly where I work we use different languages for our projects, but we're in a web environment where it's easier to build things this way.
The brief explains why the artists don't think it qualifies as a work for hire. Basically, it's because they don't receive any of the normal compensation one would get for a work for hire; they're not paid, they don't receive benefits, they just get a loan. They pay the expense of recording the album; they decide what goes into it. And they provide the legal references to back up their viewpoint. A contract that is direct contradiction to the law isn't necessarily valid, even if it's signed.
Their goal is to make sure that recordings are not considered works for hire. Currently the law is on their side. As a work for hire, if they terminate their contracts with the label they don't get to recover their copyright. This isn't about nullifying the contract; it's about what happens when the contract is terminated.
If more states hold out, stronger restrictions may end up being imposed anyway, and perhaps it will become clear to the DoJ that settling wasn't the right thing to do. (Stop laughing. Some of us would like to hang on to at least a shred of hope.)
Ultimately there are too many applications that run over the web that have to have session identifiers. Sometimes it's so that it can identify returning visitors, sometimes it's so it can just track some current information (like your shopping cart). Somewhere, it's going to have to stick that session identifier in there.
You can put it in the cookie, but that means people who disable cookies on general principles can't use your site. Sort of a nuisance.
You can put in on the URL, but if you do that, you have to be aware that people may send URLs containing session identifiers to their friends by e-mail, or they might post them to a newsgroup, or better yet, they might just put up their own web site with a link with that ID in it. I've seen all three in sites I've worked on that use URL-rewriting.
Because we wanted to avoid cookies, we started checking referrers on inbound requests. Yes, of course referrer can be spoofed; that's not the issue. We simply wanted to catch casual sharing of URLs containing session identifiers. Any referrer that doesn't match the site of the actual request, or where the session ID is different than the one in the request, is rejected; a new session is established at that point. If the request was for an interior page that requires logging in first, the user then gets booted back to the site entrance or a login page.
It really depends on whether you want to go ahead and use cookies or not. I prefer not. Cookies certainly are not the only way to manage sessions.
Then it's MSN that is flawed, not the protocol.
I think the benefits of user-agent strings outweigh the disadvantages. Yes, some sites may elect to block you based on your user-agent strings. Fine; you provided the string, you can change it. In exchange, you get the ability of the server to work around known buggy clients; to serve up content that might break other user-agents; to collect usage statistics (knowing that it can be skewed). Of these, the second is the most important. I'm starting to use this to serve up different JavaScript based on the user-agent, because this reduces the bandwidth consumption by the client (it's not downloading code it won't use).
And in extreme cases, I can actually see a need to use this. Let's say you find a version of SSH which is critically flawed, such that it will compromise the encryption process and make your session essentially plaintext. The server recognizes your version and refuses to allow you to connect, telling you you must upgrade. That might actually be a good thing.
The problem here is that Microsoft used its monopoly power on the OS to leverage a near-monopoly on the browser (my last stats indicated about 85% of visitors were IE). Now they're using that near-monopoly, in concert with the rollout of Windows XP and all the services it has tied to MSN, to turn MSN into a monopoly-like site, one you have to deal with in order to do anything on the web. Sure, they say you can run all that lovely
They're just tying it all together. The only surprising thing here is that they had the balls to go this far, not that they wanted to do it.
Red Hat Watch is a good list for being notified of patches. BugTraq is great if you want to know about the holes as they're discovered, which may be before the patch is announced.
That depends on how your corporate environment is set up. I expect that plenty of corporations that use Linux on their servers still use Windows on the desktop, and actual logins to the servers is severely restricted. (After all, your typical office worker can barely handle a DOS prompt, let alone a UNIX shell.) So it's not good, but it's still not a remotely-exploitable root hole.
Of course all corporate networks should be reasonably segmented so that compromise in one doesn't automatically compromise the entire network, but few businesses are willing to set up their network that way, probably because they're not sufficiently paranoid.
While it's true that this is a nasty, bad root exploit... at least it's a LOCAL exploit. You have to already have local access to the machine in order to take advantage of it.
The IIS holes of late have been REMOTE exploits. Any half-wit script kiddie can take advantage of it.
This is a fair point. It's also worth noting that overflows in browsers (IE) would need tuning since there are so many different versions of key DLLs floating around for it.
However it's obvious that IIS is fairly consistent throughout the NT/2K server realm, given the number of systems infected by Code Red. So while it's not exactly monoculture, it's still fairly homogenous!
No, it's probably that you forgot to include space for the NUL character to terminate the string. You need char username[9]; and then you still be paranoid about checking the length.
Even if Linux gained market dominance, it wouldn't quite be the monoculture that Windows is. There are many distributions of Linux, which put important files in different places. This isn't insurmountable but it does make writing a worm capable of running rampant a wee bit harder.
Also, it's my experience that (for now) people who set up Linux to run on the net are a little bit more clueful than NT administrators. NT seems to encourage the idea that any moron can run it because it's point and click. This isn't true; it takes more work to effectively admin an NT box than a Linux box.
There have and will continue to be worms. Worms are most successful at any point of monoculture. (sendmail; bind; IIS) The solution, then, is not dominance... but diversity.
Not only that, but the absentee vote wasn't even counted in many states because there weren't enough of them to make a difference in the outcome of the electoral vote... but it would have made a big difference in the popular vote, which was very close.
We will never know who actually won the popular vote. To cotinue to say that Gore won the popular vote is like saying Gore won the election... so long as you don't count any of the states he lost in.
And the old links now redirect to the new site at CASA.
It's just the pipe out to the net is clogged, the CPU is 91% idle right now. I'm sorry it's not the world's fattest pipe, but it does handle normal traffic without problems. Bandwidth costs money, y'know? Keep trying and your requests may squeak through.
Anyone who wants to mirror the entire page, with the embedded graphics, is welcome to, to make the material more accessible. Steve updates this page from time to time, so don't expect your mirror to stay current forever.
Those of you who scoff and say you don't have time to implement good software are shooting yourselves in the foot.
Where I work, we've developed a lot of code. We re-use as much as we can. And because a lot of our code isn't simple/elegant/pretty, it takes us more time to re-use that code than it should. It's still faster than rewriting the code but it's nowhere near as effective as it could be.
So earlier this year I began pushing for a major project to refactor and clean up this code. Already the initial stages of this project (implemented by several programmers on our staff) have yielded huge gains in how quickly we can develop stuff. As we continue to clean and simplify, these gains increase.
This is real-world. We have deadlines just as impossible as anyone else. We're doing this effort so that we can meet these deadlines on more and more projects.
If you ever plan on using that code again, write it clean. You'll thank yourself later.
I tried exactly the same thing. I had a private e-mail address that I never used for Usenet, never posted to a web site, never gave to anyone except people I wanted to hear from. Since I run my own domain, I was able to make up a new e-mail address every time I had to give one out to an untrustworthy site registration. (And in some cases caught them giving my address to spammers.)
That all lasted until two people separately posted my private e-mail address to web pages they made. That's it. Just two pages. Since then, the amount of spam delivered to that address has skyrocketed; I now get 10-20 per day.
A week ago I investigated a spam mail forwarded from a friend who was concerned. It was a scam to extract credit card numbers from unwitting newbies, and the levels to which this PacBell DSL user went to hide their origins was amazing. Spammers too often use stolen credit card numbers to get new dial-up accounts, from which they spam open relays. Fixing SMTP will help, but not eliminate the problem. Spammers will keep trying because they're not paying anything.
The net appliance thing has always been a mixed bag. There are plenty of people for whom it's all they need; an easy box to check mail and surf the web. I think the PS2 running Linux, provided that Linux is hidden from view and the user is presented with a "dummy" sort of interface, could do quite well. But it's not in any way intended for the /. crowd.
Of course I'm not saying Sony would be any better than MS. But I think this could be a pretty good thing, overall.
Try this link instead.
Fractal images don't have infinite detail because computers can't render an infinite number of pixels or perform an infinite number of iterations. However, if either of those two feats could be accomplished, the graph of the equation would have an infinite frequency spectrum, infinite detail.
Ultra Fractal (Windows)
Iterations, Flarium24, Vchira, Ktaza, TieraZon (Windows)
Fractal Domains (Mac)
There's lots of other stuff out there.