i used to have the thing where my speakers would pick up a radio station... of course that was when i lived in a dorm with the college radio station's antenna on it, and damn near everything picked up the radio station. (I'm pretty sure they didn't have appropriate isolation circuitry for the power to send out the signal, so the signal was imposed on the AC lines)
Have you been able to determine which station it is, and if its AM or FM? The station at my school was FM, but I don't think my speakers can 'decode' fm by themselves:)
I think it'd be appropriate to pass the legal buck onto the client. If the RIAA comes knocking and says 'you have this on your network', you notify the customer, and ask them to either take off the network or declare that it is not in violation of their license to share it like that. Then when the RIAA comes back, you show them the declaration, and tell them to pursue the matter with your client.
my point is, that if somebody is sharing it w/ file sharing program of the day today, and you block that, tommorow they will probably share it with file sharing program of tommorow.
trading opensource/freeware, etc, and copyrighted music that people don't care if you trade is not illegal.
there are plenty of legitimate uses for kazaa...
also, the previous poster was not suggested specifically enabling any p2p apps, just setting up QOS so the important apps have priority, and anything else can fight for the rest of the bandwidth
sounds like a good way to keep the important stuff going, and the non important stuff out of your hair
Later on that day, I attempted to locate another copy locally, but was unable to do so. I then called a CompUSA store at a different location, and after explaining my situation to the Manager on Duty, he gave me an entirely different story: he said that I could return the software if I didn't agree with the license, so long as the seal on the CD wasn't broken. This is what I expected to hear in the first place. I then went back to CompUSA to purchase the software a second time. Funny thing is, as soon as I returned home and opened the box, I discovered that this software wasn't packaged in sealed CD cases like I'd seen before. After reading the license, I decided that it was ok - but I do wonder what would have happened had I decided that I wanted to return it.
I think it would make everybody's job easier if the EULA was part of the printed material distributed in the box, and the cd was individually sealed. Then you could open the box, read the EULA, and return it if the terms were not acceptable; the retail store wouldn't have to worry that you had used the disc, since its individually sealed. Of course this gets to be a problem if you have a visual imparement, so the EULA is not accessable unless machine readable, or if the EULA on the disc is different than the EULA on the paper.
since you're mentioning the ucc, you should know that it states that in contracts for sale of goods, no additional consideration is required for a modified contract to be binding.
I would argue that the physical media and manuals etc would be goods, and that the license to use the software is services. I don't know that owning the physical media implies a license to use the software though. In many cases, software companies are willing to send you copies of physical media which will allow you to have many licensing arangements, depending on what you've paid for the use of the software. Certainly use of the software would be consideration, if having the physical media only implies you're entitled to look at it and notice its shiny qualities.
Since you said they let you know about the credit check, etc, after they offered you employment and you accepted, you can probably tell them to shove it.
Since you accepted their offer of employment w/out a credit check, you are under no obligation to have the credit check done. Furthermore, by requesting the credit check, and pressuring you into it, they are creating a hostile work environment. If I were you, I'd go talk to a lawyer and see what kind of an action you can bring against them. After all, why work for a dumb company, when you can get a settlement from a dumb company?
for quite a while (at least 3 years), their client has been able to do this. One of the problems is that it picks a way it wants the connection to go, and if the 'server' of that layout is behind a firewall that drops packets (rather than reject them), it will take quite a while for the connection attempt to time out and reverse directions.
in that situation, its best to establish a 'direct im ' connection first, in the way that works quickly, and then send files
do you also block traffic to login.icq.com? if you authenticate to that w/ the aim client, you can still get on aim.... and if you did that on port 80, then your firewall would be circumvented
i would also recommend using an.htaccess (or the like) to have the webserver itself authenticate you, in case there are any backdoors in the script (that your audit of the code doesn't show)
on my system (running debian unstable) the apache binary (/usr/sbin/apache) is owned by root and is only writable by root (why it needs to be writable, i don't know, but *shrug*), additionally the directory it is in is also only writable by root. Additionally the log directory and the logs are also only writable by root.
if i was hosting web sites for customers, I would enable suexec, so that customers' poorly secured web scripts would only damage their own stuff, and not go around screwing with the limited number of things that are writable by the www-data user (i don't think there are all that many)
There is of course the issue of php, which doesn't do the suexec thing as far as i know, but i'm sure with a lot of kicking and screaming, a solution could be aranged, or i could just not let customers run php.
While you make a good point, software engineering for an embedded system (like the ariane rocket example) would not be a pain in the arse, since the specifications of the system will be very definite.
I imagine at some point, there will be an OS that is developed with engineering principles in mind that combined with drivers developed similarly will provide a reliable and predictable OS. An OS that is reliable and predicitable will atract developers and uses.
Ideally, you'ld want to pull a bunch of Software Engineering majors off the assembly line, so you wouldn't have to spend as long training them, and there is some learning curve, so while initially they will increase the error rate, after some (probably about a year, i'd estimate, although it depends on the quality of training) on the job experience, their error rate will be on par with the rest of the company.
I do not personally know of any studies that would prove my comments right, but they probably exist, I would imagine SEI has done some.
Most of the software industry is operating in chaos because it is has the least initial cost to get into the software industry. Having a structured process requires quite a bit of initial investment, since you need to develop the process, train your staff, and you do not get the payoff until you have run through several development cycles.
But what if you are doing something no one has done before? Software engineering simply doesn't have anything to say. Computer science involves developing means for information processing, much like X engineering is limited by whatever X is (i.e, "mechanical" engineering). But that computer science deals with "information" doesn't really limit it at all.
In any engineering disciple, if you are honestly doing something that no one has done before, then X enginneering isn't going to have much to say. Engineering is really about doing things over and over again, only hopefully better each time. The first time something is done, its likely to be done by an artist, or a skilled craftsman. After a while of that, it is likely that a scientist (or several) will study this. Finally, engineers will be able to add it to their skill set. Nothing prevents you from being an artist, a scientist and an engineer for the same project....
While it is quite true that often software developers are called software engineers, there is actually such a thing as software engineering.
As others have mentioned software engineering is about developing and using an engineering process when developing software. Just as in the beginning of engineering bridges, many people who 'engineered' bridges did not practice what we would consider to be anything near engineering today; there will (hopefully) be a time when we will look back at the present (and the recent past) with awe that so much software was made without sound engineering practices.
The goals of any mature engineering discipline include providing complete designs, reasonably accurate forcasts of time for development, safety considerations, and generally some sort of societal good.
Software Engineering is still very much in its infancy, ABET, the organization which accredits engineering schools in the united states has yet to accredit any software engineering programs, but that will probably change within 2 to 3 years. Additionally, only one state, Texas, recognizes and licenses Software Engineers. I expect that within 10 years, most states will license software engineers.
I also expect that within the next 10 years, software engineering as an engineering discipline will grow in recognition, as its benefits become redily apparent by prominent examples of software engineering (for example, when some major company starts following its forecast timetables and its software is not terribly buggy). I imagine that while use of traditional software development will decline, it will continue for many years to come.
For further information on software engineering, look at Watts Humphrey's A Discipline for Software Engineering or google on 'CMMI'.
In any field where the client is not very familiar, part of engineering is working with the client to get usable requirements.
Of course, even if the client is experienced in the field, engineers will probably need to work with the client to more completely specify their design.
Slashdot Mirror
why do raid 1 + 5 when you can just put more spares in the raid 5?
i'd assume since the poster mentioned raid, he was thinking raid 5, or at least 1 + 0... so actually a node going down wouldn't be a big deal
i used to have the thing where my speakers would pick up a radio station... of course that was when i lived in a dorm with the college radio station's antenna on it, and damn near everything picked up the radio station. (I'm pretty sure they didn't have appropriate isolation circuitry for the power to send out the signal, so the signal was imposed on the AC lines)
:)
Have you been able to determine which station it is, and if its AM or FM? The station at my school was FM, but I don't think my speakers can 'decode' fm by themselves
using the right client, ie wget, you can resume from http streams provided the server supports it (and i think most modern ones do)
in soviet russia, new, slower chips announce you!
I think it'd be appropriate to pass the legal buck onto the client. If the RIAA comes knocking and says 'you have this on your network', you notify the customer, and ask them to either take off the network or declare that it is not in violation of their license to share it like that. Then when the RIAA comes back, you show them the declaration, and tell them to pursue the matter with your client.
my point is, that if somebody is sharing it w/ file sharing program of the day today, and you block that, tommorow they will probably share it with file sharing program of tommorow.
trading opensource/freeware, etc, and copyrighted music that people don't care if you trade is not illegal.
there are plenty of legitimate uses for kazaa...
also, the previous poster was not suggested specifically enabling any p2p apps, just setting up QOS so the important apps have priority, and anything else can fight for the rest of the bandwidth
sounds like a good way to keep the important stuff going, and the non important stuff out of your hair
blocking kazaa or the file trading program of the day doesn't equal removing the copyrighted media, does it?
I think it would make everybody's job easier if the EULA was part of the printed material distributed in the box, and the cd was individually sealed. Then you could open the box, read the EULA, and return it if the terms were not acceptable; the retail store wouldn't have to worry that you had used the disc, since its individually sealed. Of course this gets to be a problem if you have a visual imparement, so the EULA is not accessable unless machine readable, or if the EULA on the disc is different than the EULA on the paper.
since you're mentioning the ucc, you should know that it states that in contracts for sale of goods, no additional consideration is required for a modified contract to be binding.
I would argue that the physical media and manuals etc would be goods, and that the license to use the software is services. I don't know that owning the physical media implies a license to use the software though. In many cases, software companies are willing to send you copies of physical media which will allow you to have many licensing arangements, depending on what you've paid for the use of the software. Certainly use of the software would be consideration, if having the physical media only implies you're entitled to look at it and notice its shiny qualities.
Since you said they let you know about the credit check, etc, after they offered you employment and you accepted, you can probably tell them to shove it.
Since you accepted their offer of employment w/out a credit check, you are under no obligation to have the credit check done. Furthermore, by requesting the credit check, and pressuring you into it, they are creating a hostile work environment. If I were you, I'd go talk to a lawyer and see what kind of an action you can bring against them. After all, why work for a dumb company, when you can get a settlement from a dumb company?
for quite a while (at least 3 years), their client has been able to do this. One of the problems is that it picks a way it wants the connection to go, and if the 'server' of that layout is behind a firewall that drops packets (rather than reject them), it will take quite a while for the connection attempt to time out and reverse directions.
in that situation, its best to establish a 'direct im ' connection first, in the way that works quickly, and then send files
thats not entirely true. If one side is able to recieve incoming connections, in general, aim will be able to negotiate a link.
do you also block traffic to login.icq.com? if you authenticate to that w/ the aim client, you can still get on aim.... and if you did that on port 80, then your firewall would be circumvented
i would also recommend using an .htaccess (or the like) to have the webserver itself authenticate you, in case there are any backdoors in the script (that your audit of the code doesn't show)
on my system (running debian unstable) the apache binary (/usr/sbin/apache) is owned by root and is only writable by root (why it needs to be writable, i don't know, but *shrug*), additionally the directory it is in is also only writable by root. Additionally the log directory and the logs are also only writable by root.
if i was hosting web sites for customers, I would enable suexec, so that customers' poorly secured web scripts would only damage their own stuff, and not go around screwing with the limited number of things that are writable by the www-data user (i don't think there are all that many)
There is of course the issue of php, which doesn't do the suexec thing as far as i know, but i'm sure with a lot of kicking and screaming, a solution could be aranged, or i could just not let customers run php.
in regards to ttt, i must add that there are dvdrips of ttt hanging out on the net now, not that i have a copy
there is something to be said about downloading a dvd rip of a movie before it makes it out of theatres (it is still in theatres right?)
While you make a good point, software engineering for an embedded system (like the ariane rocket example) would not be a pain in the arse, since the specifications of the system will be very definite.
I imagine at some point, there will be an OS that is developed with engineering principles in mind that combined with drivers developed similarly will provide a reliable and predictable OS. An OS that is reliable and predicitable will atract developers and uses.
Ideally, you'ld want to pull a bunch of Software Engineering majors off the assembly line, so you wouldn't have to spend as long training them, and there is some learning curve, so while initially they will increase the error rate, after some (probably about a year, i'd estimate, although it depends on the quality of training) on the job experience, their error rate will be on par with the rest of the company.
I do not personally know of any studies that would prove my comments right, but they probably exist, I would imagine SEI has done some.
Most of the software industry is operating in chaos because it is has the least initial cost to get into the software industry. Having a structured process requires quite a bit of initial investment, since you need to develop the process, train your staff, and you do not get the payoff until you have run through several development cycles.
(ignore the sig, this is not a troll)
In any engineering disciple, if you are honestly doing something that no one has done before, then X enginneering isn't going to have much to say. Engineering is really about doing things over and over again, only hopefully better each time. The first time something is done, its likely to be done by an artist, or a skilled craftsman. After a while of that, it is likely that a scientist (or several) will study this. Finally, engineers will be able to add it to their skill set. Nothing prevents you from being an artist, a scientist and an engineer for the same project....
(ignore the sig, this is not a troll)
While it is quite true that often software developers are called software engineers, there is actually such a thing as software engineering.
As others have mentioned software engineering is about developing and using an engineering process when developing software. Just as in the beginning of engineering bridges, many people who 'engineered' bridges did not practice what we would consider to be anything near engineering today; there will (hopefully) be a time when we will look back at the present (and the recent past) with awe that so much software was made without sound engineering practices.
The goals of any mature engineering discipline include providing complete designs, reasonably accurate forcasts of time for development, safety considerations, and generally some sort of societal good.
Software Engineering is still very much in its infancy, ABET, the organization which accredits engineering schools in the united states has yet to accredit any software engineering programs, but that will probably change within 2 to 3 years. Additionally, only one state, Texas, recognizes and licenses Software Engineers. I expect that within 10 years, most states will license software engineers.
I also expect that within the next 10 years, software engineering as an engineering discipline will grow in recognition, as its benefits become redily apparent by prominent examples of software engineering (for example, when some major company starts following its forecast timetables and its software is not terribly buggy). I imagine that while use of traditional software development will decline, it will continue for many years to come.
For further information on software engineering, look at Watts Humphrey's A Discipline for Software Engineering or google on 'CMMI'.
(ignore the sig, this is not a troll)
In any field where the client is not very familiar, part of engineering is working with the client to get usable requirements.
Of course, even if the client is experienced in the field, engineers will probably need to work with the client to more completely specify their design.
(ignore my sig, this post is not a troll)
In soviet russia, 802.11b controlled destroyers wardrive you!
In soviet russia, budding 3d libraries program you.