On MacOS X, the X server also runs as the logged-in user.
That isn't really a valid comparison, since Mac OS X doesn't run X natively. You can run an X server as an application, but that X server doesn't drive any hardware, it is just yet another application using the Mac OS X graphics system (which is otherwise incompatible with all other operating systems known to me). It's just like running an X server on Windows or Xnest on something else (I think Xnest is able to make a few shortcuts because it happens to be implementing X on top of X, but it still doesn't need special privileges since it isn't controlling the hardware itself).
Well, yes, that was the point: GUI architectures that don't require a monolithic process running as root to do everything between the physical display and application code are not new. On MacOS and Darwin, X11 runs as the logged in user and like all other apps that need to draw or get keyboard and mouse events, it talks to WindowServer *which runs as a restricted user* and itself isn't handling hardware directly. That architecture is a descendant of NextStep, i.e. it predates Linux.
On MacOS X, the X server also runs as the logged-in user.
It isn't clear what "nerdyH" means by its last sentence, which doesn't really make a lot of sense. No one who cares about security puts unshielded X Windows sessions on insecure networks, because X Windows data streams between clients (e.g. xterm, Firefox, the Gnome or KDE desktops, or almost anything graphical on any Linux machine) and display servers (the piece that 'serves' a display device to clients) are not encrypted. Remote X Windows sessions are usually kept on private networks or tunneled through SSH. What this protects against is not snooping, but rather against some as-yet-unknown bug in the X server allowing code injection as root. That's a good thing, but it isn't huge. For a system distro, it could be made meaningless by the integrator giving the logged-in user excessive capabilities. To balance my first sentence: Apple provided examples of that in early versions of MacOS X, where file and directory permissions made privilege escalation trivial.
As the AC said, the chemistry doesn't matter. Energy is mass; it's just hard to convert significant amounts of one to the other. It doesn't matter if the energy is chemical, nuclear, kinetic, gravitational.
It's just (much) easier to see the change in mass in a nuclear reaction than in a chemical one.
You can say that as many times as you like, but that does not make it so. All of the English and Business majors failing Physics 101 can write in on their final exams every semester as an explanation of "E=mc^2," and some have, but it remains simply: not so. If you had the right sort of teacher in high school, the logical proof that mass and energy are very different things would jump out at you from "E=mc^2" itself.
BTW, if the released energy from the chemical reaction all went to heat in the solution, none of which escapes, then the mass of the solution wouldn't change. All that matters (no pun intended) is how much energy enters or leaves the system - there is a corresponding change in mass.
Cooling something (i.e. removing energy) does not cause a drop in mass, as you imply. It is possible to look at the energy lost by cooling in E=mv^2 terms, but the energy lost in cooling does not result in a loss of rest mass.
If you look at the break in classical kinetics that led Einstein to Special Relativity, you'll have a better understanding of it. There is *some* relativistic change in mass whenever an object's speed changes, and there are speed changes (of electrons and atoms) involved in chemical reactions, heating, and cooling, but those changes in relativistic mass do not add up to net changes in rest mass.
Nuclear fission and fusion and other sub-atomic interactions (such as those done in particle accelerators) are different because they destroy (and occasionally create) particles with non-zero rest mass.
No. vix.com is Paul's personal domain. isc.org is the Internet Systems Consortium, which he heads. ISC is a non-profit that is the custodian for BIND, the reference DHCP implementation, and a few other bits of open source software. It would be at odds with reality to confuse and conflate the two. This is particularly true in regards to actually "doing the work" for developing BIND, since Paul explicitly stayed out of the v9 code, and has publicly referred to the v4 and v8 code as evidence against his programming skills.
It is easy to find a handful of people who seem to think that Paul Vixie is a Mephistophelean figure and that ISC is just a sock puppet for him, but you can also find people who will insist that Queen Elizabeth runs the global drug trade or that Barack Obama is a Muslim.
Yeah, 'cuz you know there's never been anyone who has set up a Twitter account that claimed to be someone else.
It just can't be done. Really.
Wanna buy a bridge?
It has been possible to sync non-Apple devices with iTunes for non-DRM content for a long time, at least on the Mac side. Some devices have done it without extra software, hooking into iTunes' USB handling directly, others have used intermediary software. The former *sounds* nice, but when a device does more than play media and keep very simplified PIM info, iTunes isn't going to meet its users' needs. So then the vendor needs to write their own tools anyway, and it stops making much sense to have the device talk to iTunes directly, since the iTunes library information and media files are usable without iTunes and the PIM data that iTunes can sync is all accessible via SyncServices. That obviously differs on Windows, but surely it must have some sort of open-access PIM data sync system... (never touch the thing myself...)
The only thing Palm seems to be doing that is really different is that apparently they've decided to go the route of mimicking an iPod: sending Apple's USB Vendor and Product ID's so that iTunes will think the Pre is an iPod. Not Wise.
Because this is in a certain limited market, the customers really only have the choice between my ISP and dial-up.
Or they could buy their connectivity the same way you do and resell it to their neighbors...
Sure, there are issues, but my point is that what you should do technically isn't really an ethical question of any difficulty. You work for the company, your boss has told you to do something that isn't illegal, and unless your customer contracts promise not to use traffic shaping, it is very hard to argue that it is unethical. Do what the boss wants. If you are routinely pegging your upstream bandwidth for long periods, you are already restricting customer traffic. As it stands, that is being done without any attention to how it happens and is almost certainly causing more trouble for customers in practice than a carefully managed traffic shaping policy would. If the company isn't going to buy more bandwidth upstream for customers, figuring out some way to allocate the bandwidth you have fairly and wisely is an ethical no-brainer. Arguably there are better approaches than targeting specific protocols, but in a small operation you may have no better option.
Where there could be a moral question is on the customer communication side. The wording commonly used in selling retail ISP services is easily misunderstood even with more traditional oversell ratios and without chronic upstream saturation. With saturation "for the better part of the day" it may be easy to make the case that what you have told customers that they are buying is actively deceptive, particularly if you've sold different classes of service differentiated by bandwidth. When you are saturated upstream, the congestion flattens the differences in bandwidth that customers can see. It is also a problem because once you have your link saturated most of the time, every new customer cuts into the quality of service you can provide existing customers. If the company can bear the discomfort of being truly honest about the situation with customers, there's no moral dilemma here. Unless the Boss is telling you to deceive customers, that's not your issue.
It's evil because it violates your privacy, and there's really no easy way to opt-out. Thankfully we at Slashdot are most likely gifted with the technological acumen to block these cookies...many others, however, won't. If I choose to browse porn while my kids/wife/whatever are asleep, I don't want Google keeping a record of that (and showing my kids a "targeted" advertisement for Hairy Hardcore Latinas Gone Loco 3.5). If it in any way gets into the wrong hands (or Google decides to switch their business strategy/privacy policy) then I could be seriously screwed if I decide to run for public office.
People who share a computer user identity with their kids/wife/whatever forfeit any expectation of privacy from those kids/wife/whatever. In the modern world it isn't just idiotic to share an account for security and privacy reasons, it is a usability problem for non-casual users.
The browser has been "tightly integrated into the operating system" for years and years. Welcome to THE YEAR 2000.
One vendor's browser has been tightly integrated into their operating systems for years and years. That vendor is not Apple.
Safari 1.0 wasn't released until mid-2003, and first shipped with MacOS X 10.3 (Panther) in October 2003, along with an aging and buggy MSIE (which was what Apple had shipped as the default browser since MacOS 8.1.) The relationship of Safari with MacOS X has never been like MSIE and Windows.
Recent versions of MacOSX have bash by default. By recent I mean 10.4 had bash, and probably 10.3 but I'm not sure.
10.3 had it. Prior versions did not.
All Linux distribs have had bash installed by default for ever. And by all I mean 99.999% of the installed base, I'm sure you can find a silly exception.
A large fraction of the Linux systems I work with are embedded versions which use things which seem to be descended from the BSD (Almquist) sh. Talking about installed base numbers is silly, because it is probably also true that 90%+ of those systems have never been seen by a competent sysadmin who has any intention of ever using anything Unixy that isn't a major Linux distro. They might as well be Windows for all of the relevance of portability....
Recent versions of Tru64... do not exist.
Obviously you are not paying attention. There was a 5.1bsomething maintenance release by HP in the last few months, and they have said that they will continue support through 2012. Whether the current version has bash I don't know, but in the real world there are still major companies running 4.0f, which I am absolutely sure does not have bash. I would not suggest the project of installing bash on Tru64 4.0f to anyone I liked.
As for the BSDs, Netcraft confirms it,.. err. I don't know, what's their default shell?
FreeBSD uses the Almquist sh and I expect the others do as well. The product of Bourne sh and ksh procreating while watching kinky csh porn...
And as for Solaris, its default shell -- a Soviet-era knock off of the original Unics v1.0 --
Hardly a knockoff. That's the real Bourne Shell, built with genuine AT&T code.
is so fucktarded that nobody in their right mind keeps it as their default shell, and I've always seen bash or zsh instead.
Which is a career-limiting choice on Solaris 9 or earlier if done to root. People who fancy themselves sysadmins have wisely been fired for it. I don't recall if Sol10 includes bash or zsh, but I've never seen an experienced Solaris admin picking either of them for personal use and it is still prudent to stick with sh for scripts that may have to run under odd circumstances and ksh for anything that might get put on a Sol9 box.
The selection of a shell for non-root interactive use is far more a matter of personal taste than the selection of what you put after #! on the first line of scripts, particularly ones that need to be functional at bad times.
There is also a system hygiene practice common on the BSD's of keeping the base system minimal and only adding on what is needed, a practice that helps in keeping systems secure and stable because they are easier to fully understand.
Yeah, you're right, installing such an experimental, little used and unmaintained software package as bash is irresponsible./facepalm
it's not necessarily irresponsible, but why bother? It's one more thing to track, because even if bash hasn't had a real vulnerability identified in a long time, it still could have one tomorrow. It's a little more backup space. It's one more thing to explain to the security auditors who treat every variance from a stock installation as something that needs explaining, on an annual basis. If it's the last Tru64 box with a lot of interactive logins in a largely-linux environment, installing bash makes a lot of sense. For a FreeBSD jail that handles one website, it probably doesn't make sense.
Wherever you want to do an awful lot of things with the input and output of) system utilities and./or bash builtins.
Look at the gargantuan effort that is the Knoppix boot scripts - I seriously doubt it would make sense to rewrite those in Python or Perl, since nearly every line is a pipe between utilities or redirection. And it works well.
I'm not familiar with Knoppix, but that is true for all boot script systems, and beyond being hard to do in something else, there are cases where it may be impossible. There are still systems out there that boot on very small root filesystems that do not have any shared libraries available until the rest of their storage is mounted, so you've got to have something small and statically linked to run the scripts that get your whole software edifice in place. You can have similar problems in some failure states, where you might like to have something run if, say,/usr suddenly vanishes or if root needs to log in on the console of a box that has dropped off the net. There are systems where/sbin/sh exists for just such reasons and is a statically linked classical Bourne shell.
Why bother with portable shell scripts, seriously? Everybody has bash installed, and/or zsh that is mostly compatible, and even then you have bash anyway. I understand retro-nostalgia and all that, but necrophilia is overrated
False.
The majority of systems I work on these days and the majority of systems I have worked on since the mid 90's have not had bash installed. That includes systems running FreeBSD, NetBSD, OpenBSD, AIX, Tru64, Solaris, MacOS, and even Linux. Current versions of some of those will usually have bash in a default installation, but some still do not. Companies running stable systems as important parts of their business do not generally upgrade their OS's just for the sake of novelty. Running older systems isn't usually about nostalgia or necrophilia, it's more often about not having any compelling reason to upgrade. There is also a system hygiene practice common on the BSD's of keeping the base system minimal and only adding on what is needed, a practice that helps in keeping systems secure and stable because they are easier to fully understand. This is also common in many virtualization environments, where a running OS instance is likely to exist for a very narrow purpose and intentionally have a stripped-down set of utilities fit to that narrow purpose.
Want your shell to be portable? Write it in Korn Shell. You will find this shell on 15 year old *NIX boxes and the script will still work with bash on Linux.
Except when it doesn't.
There are differences between bash and ksh, and between different versions of ksh. In some cases the difference means syntax errors, but sometimes it can be more subtle and a script written for ksh runs just fine but doesn't do in bash what it did in ksh, or doesn't do in pdksh what it does in ksh88.
It is also not the case that ksh exists everywhere. It wasn't on MacOS until 10.4. It isn't on FreeBSD by default. It isn't on many Linux boxes, particularly the small network devices that use stripped-down systems. If you don't work in a broad variety of systems you may not need to understand the issues of shell portability, but if you don't understand them you aren't really prepared to work on different sorts of systems.
Is this even relevant anymore? Does anyone even care?
There are a lot of companies (particularly "old economy" ones) who bought the Netscape server back when there were concrete advantages to doing so who have built up complex ecosystems around it: other software, ways of working, and skillsets that have accumulated and evolved organically for a decade based on the Netscape/iPlanet/SunOne webserver. Those would have to be replaced wholesale if they decided to switch to another platform, and that's not a simple or inexpensive project. I've worked at a few such places, and the complexity of those Netscape-based environments was enough in 2 cases to kill off top-down crusades to establish Windows-everywhere systems (i.e. switching to IIS) even with the burden of Sun's licensing fees for version upgrades. Today's fad-inspired decree from above is more likely to be Apache, and that's harder to fight with Sun keeping their product proprietary. The opening of Netscape core (particularly on a BSD license) removes an advantage for an Apache-based environment, and should help keep some Sun customers on board at a time when Sun needs all the help they can get in that area.
My bank doesn't tell me to back up my account details in case their internet service goes down,
Absolutely true. Anyone who needs to actually be reminded by their bank that they should keep independent copies of their statements and an independent record of their transactions is someone who needs to have a competent adult acting as their legal guardian.
why should anything else be different?
I don't know that I'd go quite so far... People have been using banks for generations, mostly with no computers involved at all, so the fact that one should have a way to check their work is pretty deeply embedded in the culture. Reliance on Internet services is quite new, so people do need to be told that they need to take steps to assure their own security.
1&1 has a practice of suspending your account and removing all data without any notice. I was running a website hosted by them, and on said site we got into a discussion about phishing. 1&1 came to the conclusion that my site was actually being used for phishing and shut it down with absolutely zero notice. I didn't find out until I tried to login to my admin panel.
And that is completely within the terms and conditions clearly linked from many (all?) of the pages on 1&1's site. Tose terms are the contract for service that they offer, and it clearly says that they can terminate service unilaterally without notice, review, or liability if they think a site is violating their usage rules. If one wants a different sort of service, one selects a different provider or negotiates a different set of terms from their norm.
If one buys their service under those terms and expects anything better or fails to read the terms, one is a blithering idiot.
1&1 is supposedly one of the biggest hosting companies in the world and I'm appalled at their actions.
I can't imagine why. Did you have some contract with them other than the one they are currently offering?
I was never able to receive any of my data, or even get any correspondence. I would say that's a pretty good definition of "eviction," and I will never do business with them again.
Not having the bulk of your data backed up independently of their systems is either an indication that you didn't really value it very highly or that you're not very bright.
Did you try dealing with the issue by asking them for an explanation and for a copy of your data? I have not dealt directly with 1and1, but I know from working with service provider policy enforcement operations that it is very rare for big providers to play "BOFH" in more than the most shallow fashion. The bulk of unilateral terminations a web hoster does are of customers who know they are living on borrowed time and don't bother trying to argue their innocence, so when they actually get someone who protests in any credible way, they usually roll over pretty easily.
300 felons recently paroled for computer and technology related crimes.
300 IT professionals who:
Are willing to answer a survey about their employers' and their own personal security practices
Are working in companies where the level of management/IT hostility and distrust is such that someone has been talking to Cyber-Ark about ways to protect company secrets from disgruntled IT staff.
Seems to me like a recipe for a sample weighted towards pissed-off incompetents.
I once got what I assumed to be an attempt at social engineering into our systems.
Caller (who did not identify himself): "Hi, would you be interested in completing a survey?"
Me (bored): "Uh, alright."
Him: "Can you outline for me the steps you take to ensure the security of your IT systems?"
Me: "Absolutely! First, I do not discuss my security configurations with unknown people. Have a nice day." and then hung up on him.
that's not just funny, it may partly explain the results of this survey. If you ask a serious pro about his active security measures, particularly the ones that are not pure technology and so are not readily detectable, he will not answer. The people who will happily chat with a vendor about IT security practices are bozos. That 88% of bozo admins are unethical is not so hard to believe.
88% though?!? That's staggering, I have a hard time believing that ethics in the IT industry are so poor to validate a number that large? I want to know details about who they surveyed to qualify that number.
RTFA
Or simply note that this survey was conducted by a company which is in the business of selling snake oil products to people who are prone to fear that their technical staff is out to screw them. Hmm... I don't suppose they would ever perform a survey in such a way as to assure that they got a paranoia-inducing outcome...
I know that the sociopath mentality is the way of the road at the top of some parts of corporate American (especially in the energy industry it would seem), and I wouldn't be surprised to see this number if it related to executives based on the nightly news, but in my IT circles we look on that behavior with scorn rather than having envy to aspire to it. And frankly I just don't see this type of thinking any place within the company I currently work for, top to bottom.
I was recently fired for the egregious misbehavior of being more expensive than a sysadmin in Mexico. I had 3 months of formal notice, and over 2 years of "writing on the wall" notice as a team of 12 was dwindled to 3. I took no data or docs out of the company that I was not authorized to take, and had to actively reject the plea that I leave myself a back door so that I could be leaned on in an emergency. In the preceding years of having the unpleasant task of "exit audits" I never found anything more heinous than sysadmins taking copies of the tools they had written for work, an act that was approved for me when I bothered asking for permission as I left.
I do not believe that this survey represents reality. It may well represent the reality of the companies Cyber-Ark has scared into buying their products.
This is really an amazing report. Frankly it makes me fearful at what type of reprise knee jerk reaction management types are going to take based on this story.
Sigh...
That seems like the entire purpose of the survey. Some will buy Cyber-Ark's products.
If this is indeed not a protocol flaw, how come the same vulnerability is present on other DNS servers as well ?
Do they all use the same code from BIND for this particular 'feature' ?
No.
The/. description of that thread is inaccurate and the behavior of BIND in breaking trustworthiness ties (which are set up by RFC2181) in favor of apparently newer records is not a bug, but rather a behavior which has been operationally useful and normal for most of the history of DNS. If you look closely at Dan Kaminski's discussion of how he came to recognize the vulnerability, it becomes clear that he was using that normal behavior and put together all of the pieces of the attack from the fact that his experimental idea to enhance availability with spoofed DNS replies was working.
With the caveat that I'm trusting the posts on bind-users rather than looking in depth at the code in question, it seems to me that this change would restrict the defined functionality of dynamic DNS, which to some degree relies on resolvers treating new records as new rather than as forged, even if the TTL of a cached record from an equivalently authoritative (apparent) source has not expired. The way DNS changes propagate in practice would be modified significantly by this, and people who have gotten away with poor planning of DNS changes in the past would be hit harder by that sloppiness if the behavior of nameservers (BIND *and* others) is switched from giving ties to the new data to giving ties to cached data.
In the end, I think that there will need to be a new RFC on DNS extending RFC2181's discussion of cache/answer conflict resolution. IMHO the likely outcome of that will be a new model for conflict resolution that will make cache poisoning a bit harder while punishing authoritative servers for zones that either change a lot or are heavy spoofing targets with both load and a requirement of pedantic correctness. The only hope for resolving a conflict correctly would be to toss out every record between the root and the point of conflict and restart a recursive resolution of the conflicted names. That is a bit ugly, but not as ugly as simply switching the way the coin is flipped on cache/answer ties.
such as *gasp* having Mom stay home and actually raise them
Because, as we all know it is impossible to raise children if one of the parents doesn't stay at home.
Other than that, I'd say your argument is pretty solid. Employers aren't responsible for an employee's children.
With the caveat that I understand that I'm hanging this off of two layers of unabashed flamebait... These bits of DUHHHH make a nice frame with the NYT story behind the "way it treats its employees" link for a missed point.
GOOGLE HAS NEVER BEEN A WORKER'S PARADISE
A lot of IT people have been contacted by Google recruiters in the past few years, sometimes in rather intrusive ways. What one can learn from being a Google recruiting target (assuming you don't just hit delete on the spam... ) is:
Google has a severe shortage of mid-career IT pros with really solid experience outside of the academic/ISP/startup world.
Google has absolutely no clue about how to appeal to those people.
At one point, an acquaintance of mine who happened to work at Google whined in a rather chatty place with a heavy population of middle-aged sysadmins about how hard it was to find experienced sysadmins, and expressed it in a way that made it clear that there's strong Kool-Aid being passed around at Google that is perpetuating the problem. Google folks seem to think that working at Google is a perk per se and many will try to sell the greatness of that honor further by talking up the many more tangible perks, never understanding that the list of goodies which must seem fabulous to someone whose work experience is Starbucks, maybe a graduate assistantship, and a failed startup is much more likely to look like a baited trap to someone who has more common sorts of serious IT experience. Ironically, the guy who was complaining a year ago about his recruiting difficulties has now left Google...
The child care fiasco is a perfect example of how Google's "good benefits" are themselves part of that problem. On-site child care is a great benefit, and is attractive to many of the people that Google has been trying desperately to attract. However, it is also most attractive to a younger set, people with preschool kids who have not reached the point of understanding that daycare is a second-best choice. For parents with a bit more experience, a gold-plated subsidized child care center at the workplace is just another bar in a gilded cage. Google is unattractive to seasoned pros because part of that seasoning includes learning that a job is rarely adequate as the primary focus of a happy life, and that if you make your job the central focus of your life you are almost certain to end up burnt out on that job and without anything else. Google has worked very hard to attract people willing and able to essentially live in the Googleplex, but by building the company on those sorts of people they have built in a blindness to the needs of the sort of people they will increasingly need to have on board as they try to offer deeper services to more demanding audiences. Of course, Google is far from the first company to have this sort of trouble. Apple, Adobe, and Microsoft have all survived their adolescence successfully and if Google figures out that it actually can learn something from what others have done in the past, they certainly have the resources to make the transition to a sustainable mature company.
You're asking a legal question anonymously and with inadequate background in a public forum not known for its big lawyer population... Keep in mind that my answer and most of the others you get here are potentially very wrong because of the lack of background and (at least in my case) only an amateur's understanding of the law. I should also add that most of what I'm saying below is not applauding the state of affairs as I understand it, just explaining it.
There are many differences between countries and almost as many between US states. The wording of the post hints at a likely US context, so I'm bloviating on the basis of that assumption. For most people in the US, a job is entirely "at will" and your employer can fire you for almost any reason other than your status as a member of an explicitly defined "protected class" covered under civil rights law. No federal or state law deems "software patent opponent" a protected class. Even in states with more extensive employment protection, it is almost always the case that anything an employee creates for an employer which is legally protectable as any sort of "intellectual property" is (with or without any formal IP agreement) the sole property of the employer, and a job that includes creating such valuable "property" as a primary role could easily be argued to include a responsibility to support the employer's protection of that value. Beyond that, many employers protect themselves from ever having to prove the arguable issues of law or fact in such cases by having employees sign a bunch of employment terms and IP handling stipulations when hired or even periodically in order to assure that everyone understands their status and remembers it. If you've signed an agreement stipulating that everything you create for your employer belongs to them and that you will help your employer defend its rights to those works for hire, you have no legal (or ethical) standing to change your mind when actually asked to do so and expect to keep your job.
That said, others have pointed out some good options for you. If your opposition to this software patent is primarily based in an article of faith that software patents are bad, you might not have noticed the pragmatically stronger opposition to software (and business process) patents: that they almost never truly fit the ideal conceptual model of what patents are supposed to be. Software patents have largely been issued without adequate expertise and understanding by the USPTO of how software is created and what actually constitutes originality and real invention, so many are conceptually weak. If you "assist" the patent process by explaining how trivially derivative the "invention" was based on lots of prior art, you may kill the whole thing.
And yes, you probably could be fired for that too, but if you are careful and make it clear that you are just being conscientious about keeping the company from wasting effort on a doomed patent, that's not so likely. If you approach it as a tenet of faith that software patents are bad and wrong and you will have no part of them, you should bring a box to work with you that day to carry out your personal belongings...
Actually, as far as I know, plant based substrates are known as epoxys.
I suggest that you try to get a refund from whatever school tried to teach you organic chemistry
Epoxy resins are formed by the combination of components that are synthesized from fossil fuel sources. The name comes from the C2O "epoxide" ring that is present in one component (usually epichlorhydrin) and survives on both ends of the epoxy polymer.
Plants are the direct source of one of the oldest, most widely used, and widely recycled polymer materials: cellulose and lignin. Plants can be the primary input to processes yielding the short-chain hydrocarbons that are used as the basic ingredients for many plastics, and there have been some processes developed recently that use lignin as the starting point for commercially usable polystyrenes and polyurethanes.
It is useful to keep in mind that all fossil fuels are the result of various sorts of biomass landing in just the right sorts of temperature and pressure conditions by the vagaries of sedimentation and plate tectonics. We know how to replicate those processes in far less time. It doesn't make sense to do so for fuel and as long as the natural stuff has been cheap and plentiful it hasn't made sense as a way to get the raw materials for plastics, but as we work our way towards the increasingly expensive dregs of naturally occurring oil, it will get more competitive to use various sorts of cultivatable life as our industrial starting points.
Slashdot Mirror
That isn't really a valid comparison, since Mac OS X doesn't run X natively. You can run an X server as an application, but that X server doesn't drive any hardware, it is just yet another application using the Mac OS X graphics system (which is otherwise incompatible with all other operating systems known to me). It's just like running an X server on Windows or Xnest on something else (I think Xnest is able to make a few shortcuts because it happens to be implementing X on top of X, but it still doesn't need special privileges since it isn't controlling the hardware itself).
Well, yes, that was the point: GUI architectures that don't require a monolithic process running as root to do everything between the physical display and application code are not new. On MacOS and Darwin, X11 runs as the logged in user and like all other apps that need to draw or get keyboard and mouse events, it talks to WindowServer *which runs as a restricted user* and itself isn't handling hardware directly. That architecture is a descendant of NextStep, i.e. it predates Linux.
On MacOS X, the X server also runs as the logged-in user. It isn't clear what "nerdyH" means by its last sentence, which doesn't really make a lot of sense. No one who cares about security puts unshielded X Windows sessions on insecure networks, because X Windows data streams between clients (e.g. xterm, Firefox, the Gnome or KDE desktops, or almost anything graphical on any Linux machine) and display servers (the piece that 'serves' a display device to clients) are not encrypted. Remote X Windows sessions are usually kept on private networks or tunneled through SSH. What this protects against is not snooping, but rather against some as-yet-unknown bug in the X server allowing code injection as root. That's a good thing, but it isn't huge. For a system distro, it could be made meaningless by the integrator giving the logged-in user excessive capabilities. To balance my first sentence: Apple provided examples of that in early versions of MacOS X, where file and directory permissions made privilege escalation trivial.
As the AC said, the chemistry doesn't matter. Energy is mass; it's just hard to convert significant amounts of one to the other. It doesn't matter if the energy is chemical, nuclear, kinetic, gravitational.
It's just (much) easier to see the change in mass in a nuclear reaction than in a chemical one.
You can say that as many times as you like, but that does not make it so. All of the English and Business majors failing Physics 101 can write in on their final exams every semester as an explanation of "E=mc^2," and some have, but it remains simply: not so. If you had the right sort of teacher in high school, the logical proof that mass and energy are very different things would jump out at you from "E=mc^2" itself.
BTW, if the released energy from the chemical reaction all went to heat in the solution, none of which escapes, then the mass of the solution wouldn't change. All that matters (no pun intended) is how much energy enters or leaves the system - there is a corresponding change in mass.
Cooling something (i.e. removing energy) does not cause a drop in mass, as you imply. It is possible to look at the energy lost by cooling in E=mv^2 terms, but the energy lost in cooling does not result in a loss of rest mass.
If you look at the break in classical kinetics that led Einstein to Special Relativity, you'll have a better understanding of it. There is *some* relativistic change in mass whenever an object's speed changes, and there are speed changes (of electrons and atoms) involved in chemical reactions, heating, and cooling, but those changes in relativistic mass do not add up to net changes in rest mass.
Nuclear fission and fusion and other sub-atomic interactions (such as those done in particle accelerators) are different because they destroy (and occasionally create) particles with non-zero rest mass.
Isn't that vix.com?
No. vix.com is Paul's personal domain. isc.org is the Internet Systems Consortium, which he heads. ISC is a non-profit that is the custodian for BIND, the reference DHCP implementation, and a few other bits of open source software. It would be at odds with reality to confuse and conflate the two. This is particularly true in regards to actually "doing the work" for developing BIND, since Paul explicitly stayed out of the v9 code, and has publicly referred to the v4 and v8 code as evidence against his programming skills.
It is easy to find a handful of people who seem to think that Paul Vixie is a Mephistophelean figure and that ISC is just a sock puppet for him, but you can also find people who will insist that Queen Elizabeth runs the global drug trade or that Barack Obama is a Muslim.
Yeah, 'cuz you know there's never been anyone who has set up a Twitter account that claimed to be someone else. It just can't be done. Really. Wanna buy a bridge?
It has been possible to sync non-Apple devices with iTunes for non-DRM content for a long time, at least on the Mac side. Some devices have done it without extra software, hooking into iTunes' USB handling directly, others have used intermediary software. The former *sounds* nice, but when a device does more than play media and keep very simplified PIM info, iTunes isn't going to meet its users' needs. So then the vendor needs to write their own tools anyway, and it stops making much sense to have the device talk to iTunes directly, since the iTunes library information and media files are usable without iTunes and the PIM data that iTunes can sync is all accessible via SyncServices. That obviously differs on Windows, but surely it must have some sort of open-access PIM data sync system... (never touch the thing myself...) The only thing Palm seems to be doing that is really different is that apparently they've decided to go the route of mimicking an iPod: sending Apple's USB Vendor and Product ID's so that iTunes will think the Pre is an iPod. Not Wise.
Because this is in a certain limited market, the customers really only have the choice between my ISP and dial-up.
Or they could buy their connectivity the same way you do and resell it to their neighbors...
Sure, there are issues, but my point is that what you should do technically isn't really an ethical question of any difficulty. You work for the company, your boss has told you to do something that isn't illegal, and unless your customer contracts promise not to use traffic shaping, it is very hard to argue that it is unethical. Do what the boss wants. If you are routinely pegging your upstream bandwidth for long periods, you are already restricting customer traffic. As it stands, that is being done without any attention to how it happens and is almost certainly causing more trouble for customers in practice than a carefully managed traffic shaping policy would. If the company isn't going to buy more bandwidth upstream for customers, figuring out some way to allocate the bandwidth you have fairly and wisely is an ethical no-brainer. Arguably there are better approaches than targeting specific protocols, but in a small operation you may have no better option.
Where there could be a moral question is on the customer communication side. The wording commonly used in selling retail ISP services is easily misunderstood even with more traditional oversell ratios and without chronic upstream saturation. With saturation "for the better part of the day" it may be easy to make the case that what you have told customers that they are buying is actively deceptive, particularly if you've sold different classes of service differentiated by bandwidth. When you are saturated upstream, the congestion flattens the differences in bandwidth that customers can see. It is also a problem because once you have your link saturated most of the time, every new customer cuts into the quality of service you can provide existing customers. If the company can bear the discomfort of being truly honest about the situation with customers, there's no moral dilemma here. Unless the Boss is telling you to deceive customers, that's not your issue.
It's evil because it violates your privacy, and there's really no easy way to opt-out. Thankfully we at Slashdot are most likely gifted with the technological acumen to block these cookies...many others, however, won't. If I choose to browse porn while my kids/wife/whatever are asleep, I don't want Google keeping a record of that (and showing my kids a "targeted" advertisement for Hairy Hardcore Latinas Gone Loco 3.5). If it in any way gets into the wrong hands (or Google decides to switch their business strategy/privacy policy) then I could be seriously screwed if I decide to run for public office.
People who share a computer user identity with their kids/wife/whatever forfeit any expectation of privacy from those kids/wife/whatever. In the modern world it isn't just idiotic to share an account for security and privacy reasons, it is a usability problem for non-casual users.
The browser has been "tightly integrated into the operating system" for years and years. Welcome to THE YEAR 2000.
One vendor's browser has been tightly integrated into their operating systems for years and years. That vendor is not Apple.
Safari 1.0 wasn't released until mid-2003, and first shipped with MacOS X 10.3 (Panther) in October 2003, along with an aging and buggy MSIE (which was what Apple had shipped as the default browser since MacOS 8.1.) The relationship of Safari with MacOS X has never been like MSIE and Windows.
Recent versions of MacOSX have bash by default. By recent I mean 10.4 had bash, and probably 10.3 but I'm not sure.
10.3 had it. Prior versions did not.
All Linux distribs have had bash installed by default for ever. And by all I mean 99.999% of the installed base, I'm sure you can find a silly exception.
A large fraction of the Linux systems I work with are embedded versions which use things which seem to be descended from the BSD (Almquist) sh. Talking about installed base numbers is silly, because it is probably also true that 90%+ of those systems have never been seen by a competent sysadmin who has any intention of ever using anything Unixy that isn't a major Linux distro. They might as well be Windows for all of the relevance of portability....
Recent versions of Tru64 ... do not exist.
Obviously you are not paying attention. There was a 5.1bsomething maintenance release by HP in the last few months, and they have said that they will continue support through 2012. Whether the current version has bash I don't know, but in the real world there are still major companies running 4.0f, which I am absolutely sure does not have bash. I would not suggest the project of installing bash on Tru64 4.0f to anyone I liked.
As for the BSDs, Netcraft confirms it, .. err. I don't know, what's their default shell?
FreeBSD uses the Almquist sh and I expect the others do as well. The product of Bourne sh and ksh procreating while watching kinky csh porn...
And as for Solaris, its default shell -- a Soviet-era knock off of the original Unics v1.0 --
Hardly a knockoff. That's the real Bourne Shell, built with genuine AT&T code.
is so fucktarded that nobody in their right mind keeps it as their default shell, and I've always seen bash or zsh instead.
Which is a career-limiting choice on Solaris 9 or earlier if done to root. People who fancy themselves sysadmins have wisely been fired for it. I don't recall if Sol10 includes bash or zsh, but I've never seen an experienced Solaris admin picking either of them for personal use and it is still prudent to stick with sh for scripts that may have to run under odd circumstances and ksh for anything that might get put on a Sol9 box. The selection of a shell for non-root interactive use is far more a matter of personal taste than the selection of what you put after #! on the first line of scripts, particularly ones that need to be functional at bad times.
There is also a system hygiene practice common on the BSD's of keeping the base system minimal and only adding on what is needed, a practice that helps in keeping systems secure and stable because they are easier to fully understand.
Yeah, you're right, installing such an experimental, little used and unmaintained software package as bash is irresponsible. /facepalm
it's not necessarily irresponsible, but why bother? It's one more thing to track, because even if bash hasn't had a real vulnerability identified in a long time, it still could have one tomorrow. It's a little more backup space. It's one more thing to explain to the security auditors who treat every variance from a stock installation as something that needs explaining, on an annual basis. If it's the last Tru64 box with a lot of interactive logins in a largely-linux environment, installing bash makes a lot of sense. For a FreeBSD jail that handles one website, it probably doesn't make sense.
Wherever you want to do an awful lot of things with the input and output of) system utilities and./or bash builtins. Look at the gargantuan effort that is the Knoppix boot scripts - I seriously doubt it would make sense to rewrite those in Python or Perl, since nearly every line is a pipe between utilities or redirection. And it works well.
I'm not familiar with Knoppix, but that is true for all boot script systems, and beyond being hard to do in something else, there are cases where it may be impossible. There are still systems out there that boot on very small root filesystems that do not have any shared libraries available until the rest of their storage is mounted, so you've got to have something small and statically linked to run the scripts that get your whole software edifice in place. You can have similar problems in some failure states, where you might like to have something run if, say, /usr suddenly vanishes or if root needs to log in on the console of a box that has dropped off the net. There are systems where /sbin/sh exists for just such reasons and is a statically linked classical Bourne shell.
Why bother with portable shell scripts, seriously? Everybody has bash installed, and/or zsh that is mostly compatible, and even then you have bash anyway. I understand retro-nostalgia and all that, but necrophilia is overrated
False.
The majority of systems I work on these days and the majority of systems I have worked on since the mid 90's have not had bash installed. That includes systems running FreeBSD, NetBSD, OpenBSD, AIX, Tru64, Solaris, MacOS, and even Linux. Current versions of some of those will usually have bash in a default installation, but some still do not. Companies running stable systems as important parts of their business do not generally upgrade their OS's just for the sake of novelty. Running older systems isn't usually about nostalgia or necrophilia, it's more often about not having any compelling reason to upgrade. There is also a system hygiene practice common on the BSD's of keeping the base system minimal and only adding on what is needed, a practice that helps in keeping systems secure and stable because they are easier to fully understand. This is also common in many virtualization environments, where a running OS instance is likely to exist for a very narrow purpose and intentionally have a stripped-down set of utilities fit to that narrow purpose.
Want your shell to be portable? Write it in Korn Shell. You will find this shell on 15 year old *NIX boxes and the script will still work with bash on Linux.
Except when it doesn't.
There are differences between bash and ksh, and between different versions of ksh. In some cases the difference means syntax errors, but sometimes it can be more subtle and a script written for ksh runs just fine but doesn't do in bash what it did in ksh, or doesn't do in pdksh what it does in ksh88.
It is also not the case that ksh exists everywhere. It wasn't on MacOS until 10.4. It isn't on FreeBSD by default. It isn't on many Linux boxes, particularly the small network devices that use stripped-down systems. If you don't work in a broad variety of systems you may not need to understand the issues of shell portability, but if you don't understand them you aren't really prepared to work on different sorts of systems.
Is this even relevant anymore? Does anyone even care?
There are a lot of companies (particularly "old economy" ones) who bought the Netscape server back when there were concrete advantages to doing so who have built up complex ecosystems around it: other software, ways of working, and skillsets that have accumulated and evolved organically for a decade based on the Netscape/iPlanet/SunOne webserver. Those would have to be replaced wholesale if they decided to switch to another platform, and that's not a simple or inexpensive project. I've worked at a few such places, and the complexity of those Netscape-based environments was enough in 2 cases to kill off top-down crusades to establish Windows-everywhere systems (i.e. switching to IIS) even with the burden of Sun's licensing fees for version upgrades. Today's fad-inspired decree from above is more likely to be Apache, and that's harder to fight with Sun keeping their product proprietary. The opening of Netscape core (particularly on a BSD license) removes an advantage for an Apache-based environment, and should help keep some Sun customers on board at a time when Sun needs all the help they can get in that area.
My bank doesn't tell me to back up my account details in case their internet service goes down,
Absolutely true. Anyone who needs to actually be reminded by their bank that they should keep independent copies of their statements and an independent record of their transactions is someone who needs to have a competent adult acting as their legal guardian.
why should anything else be different?
I don't know that I'd go quite so far... People have been using banks for generations, mostly with no computers involved at all, so the fact that one should have a way to check their work is pretty deeply embedded in the culture. Reliance on Internet services is quite new, so people do need to be told that they need to take steps to assure their own security.
I'd like for web.archive.org to be more reliable.
If that's the truth, then surely you've been to the right place to get that done.
Which is why noone is discussing suing aol for damages in this case, instead the discussion is about changing the law.
Because no one old enough (and mentally competent) to sue actually believes that AOL has done anything that they can be sued for.
1&1 has a practice of suspending your account and removing all data without any notice. I was running a website hosted by them, and on said site we got into a discussion about phishing. 1&1 came to the conclusion that my site was actually being used for phishing and shut it down with absolutely zero notice. I didn't find out until I tried to login to my admin panel.
And that is completely within the terms and conditions clearly linked from many (all?) of the pages on 1&1's site. Tose terms are the contract for service that they offer, and it clearly says that they can terminate service unilaterally without notice, review, or liability if they think a site is violating their usage rules. If one wants a different sort of service, one selects a different provider or negotiates a different set of terms from their norm.
If one buys their service under those terms and expects anything better or fails to read the terms, one is a blithering idiot.
1&1 is supposedly one of the biggest hosting companies in the world and I'm appalled at their actions.
I can't imagine why. Did you have some contract with them other than the one they are currently offering?
I was never able to receive any of my data, or even get any correspondence. I would say that's a pretty good definition of "eviction," and I will never do business with them again.
Not having the bulk of your data backed up independently of their systems is either an indication that you didn't really value it very highly or that you're not very bright.
Did you try dealing with the issue by asking them for an explanation and for a copy of your data? I have not dealt directly with 1and1, but I know from working with service provider policy enforcement operations that it is very rare for big providers to play "BOFH" in more than the most shallow fashion. The bulk of unilateral terminations a web hoster does are of customers who know they are living on borrowed time and don't bother trying to argue their innocence, so when they actually get someone who protests in any credible way, they usually roll over pretty easily.
as for who they actually ... who knows?
300 felons recently paroled for computer and technology related crimes.
300 IT professionals who:
Seems to me like a recipe for a sample weighted towards pissed-off incompetents.
I once got what I assumed to be an attempt at social engineering into our systems.
Caller (who did not identify himself): "Hi, would you be interested in completing a survey?"
Me (bored): "Uh, alright."
Him: "Can you outline for me the steps you take to ensure the security of your IT systems?"
Me: "Absolutely! First, I do not discuss my security configurations with unknown people. Have a nice day." and then hung up on him.
that's not just funny, it may partly explain the results of this survey. If you ask a serious pro about his active security measures, particularly the ones that are not pure technology and so are not readily detectable, he will not answer. The people who will happily chat with a vendor about IT security practices are bozos. That 88% of bozo admins are unethical is not so hard to believe.
88% though?!? That's staggering, I have a hard time believing that ethics in the IT industry are so poor to validate a number that large? I want to know details about who they surveyed to qualify that number.
RTFA
Or simply note that this survey was conducted by a company which is in the business of selling snake oil products to people who are prone to fear that their technical staff is out to screw them. Hmm... I don't suppose they would ever perform a survey in such a way as to assure that they got a paranoia-inducing outcome...
I know that the sociopath mentality is the way of the road at the top of some parts of corporate American (especially in the energy industry it would seem), and I wouldn't be surprised to see this number if it related to executives based on the nightly news, but in my IT circles we look on that behavior with scorn rather than having envy to aspire to it. And frankly I just don't see this type of thinking any place within the company I currently work for, top to bottom.
I was recently fired for the egregious misbehavior of being more expensive than a sysadmin in Mexico. I had 3 months of formal notice, and over 2 years of "writing on the wall" notice as a team of 12 was dwindled to 3. I took no data or docs out of the company that I was not authorized to take, and had to actively reject the plea that I leave myself a back door so that I could be leaned on in an emergency. In the preceding years of having the unpleasant task of "exit audits" I never found anything more heinous than sysadmins taking copies of the tools they had written for work, an act that was approved for me when I bothered asking for permission as I left.
I do not believe that this survey represents reality. It may well represent the reality of the companies Cyber-Ark has scared into buying their products.
This is really an amazing report. Frankly it makes me fearful at what type of reprise knee jerk reaction management types are going to take based on this story.
Sigh...
That seems like the entire purpose of the survey. Some will buy Cyber-Ark's products.
If this is indeed not a protocol flaw, how come the same vulnerability is present on other DNS servers as well ?
Do they all use the same code from BIND for this particular 'feature' ?
No.
The /. description of that thread is inaccurate and the behavior of BIND in breaking trustworthiness ties (which are set up by RFC2181) in favor of apparently newer records is not a bug, but rather a behavior which has been operationally useful and normal for most of the history of DNS. If you look closely at Dan Kaminski's discussion of how he came to recognize the vulnerability, it becomes clear that he was using that normal behavior and put together all of the pieces of the attack from the fact that his experimental idea to enhance availability with spoofed DNS replies was working.
With the caveat that I'm trusting the posts on bind-users rather than looking in depth at the code in question, it seems to me that this change would restrict the defined functionality of dynamic DNS, which to some degree relies on resolvers treating new records as new rather than as forged, even if the TTL of a cached record from an equivalently authoritative (apparent) source has not expired. The way DNS changes propagate in practice would be modified significantly by this, and people who have gotten away with poor planning of DNS changes in the past would be hit harder by that sloppiness if the behavior of nameservers (BIND *and* others) is switched from giving ties to the new data to giving ties to cached data.
In the end, I think that there will need to be a new RFC on DNS extending RFC2181's discussion of cache/answer conflict resolution. IMHO the likely outcome of that will be a new model for conflict resolution that will make cache poisoning a bit harder while punishing authoritative servers for zones that either change a lot or are heavy spoofing targets with both load and a requirement of pedantic correctness. The only hope for resolving a conflict correctly would be to toss out every record between the root and the point of conflict and restart a recursive resolution of the conflicted names. That is a bit ugly, but not as ugly as simply switching the way the coin is flipped on cache/answer ties.
such as *gasp* having Mom stay home and actually raise them
Because, as we all know it is impossible to raise children if one of the parents doesn't stay at home.
Other than that, I'd say your argument is pretty solid. Employers aren't responsible for an employee's children.
With the caveat that I understand that I'm hanging this off of two layers of unabashed flamebait... These bits of DUHHHH make a nice frame with the NYT story behind the "way it treats its employees" link for a missed point.
GOOGLE HAS NEVER BEEN A WORKER'S PARADISE
A lot of IT people have been contacted by Google recruiters in the past few years, sometimes in rather intrusive ways. What one can learn from being a Google recruiting target (assuming you don't just hit delete on the spam... ) is:
At one point, an acquaintance of mine who happened to work at Google whined in a rather chatty place with a heavy population of middle-aged sysadmins about how hard it was to find experienced sysadmins, and expressed it in a way that made it clear that there's strong Kool-Aid being passed around at Google that is perpetuating the problem. Google folks seem to think that working at Google is a perk per se and many will try to sell the greatness of that honor further by talking up the many more tangible perks, never understanding that the list of goodies which must seem fabulous to someone whose work experience is Starbucks, maybe a graduate assistantship, and a failed startup is much more likely to look like a baited trap to someone who has more common sorts of serious IT experience. Ironically, the guy who was complaining a year ago about his recruiting difficulties has now left Google...
The child care fiasco is a perfect example of how Google's "good benefits" are themselves part of that problem. On-site child care is a great benefit, and is attractive to many of the people that Google has been trying desperately to attract. However, it is also most attractive to a younger set, people with preschool kids who have not reached the point of understanding that daycare is a second-best choice. For parents with a bit more experience, a gold-plated subsidized child care center at the workplace is just another bar in a gilded cage. Google is unattractive to seasoned pros because part of that seasoning includes learning that a job is rarely adequate as the primary focus of a happy life, and that if you make your job the central focus of your life you are almost certain to end up burnt out on that job and without anything else. Google has worked very hard to attract people willing and able to essentially live in the Googleplex, but by building the company on those sorts of people they have built in a blindness to the needs of the sort of people they will increasingly need to have on board as they try to offer deeper services to more demanding audiences. Of course, Google is far from the first company to have this sort of trouble. Apple, Adobe, and Microsoft have all survived their adolescence successfully and if Google figures out that it actually can learn something from what others have done in the past, they certainly have the resources to make the transition to a sustainable mature company.
You're asking a legal question anonymously and with inadequate background in a public forum not known for its big lawyer population... Keep in mind that my answer and most of the others you get here are potentially very wrong because of the lack of background and (at least in my case) only an amateur's understanding of the law. I should also add that most of what I'm saying below is not applauding the state of affairs as I understand it, just explaining it.
There are many differences between countries and almost as many between US states. The wording of the post hints at a likely US context, so I'm bloviating on the basis of that assumption. For most people in the US, a job is entirely "at will" and your employer can fire you for almost any reason other than your status as a member of an explicitly defined "protected class" covered under civil rights law. No federal or state law deems "software patent opponent" a protected class. Even in states with more extensive employment protection, it is almost always the case that anything an employee creates for an employer which is legally protectable as any sort of "intellectual property" is (with or without any formal IP agreement) the sole property of the employer, and a job that includes creating such valuable "property" as a primary role could easily be argued to include a responsibility to support the employer's protection of that value. Beyond that, many employers protect themselves from ever having to prove the arguable issues of law or fact in such cases by having employees sign a bunch of employment terms and IP handling stipulations when hired or even periodically in order to assure that everyone understands their status and remembers it. If you've signed an agreement stipulating that everything you create for your employer belongs to them and that you will help your employer defend its rights to those works for hire, you have no legal (or ethical) standing to change your mind when actually asked to do so and expect to keep your job.
That said, others have pointed out some good options for you. If your opposition to this software patent is primarily based in an article of faith that software patents are bad, you might not have noticed the pragmatically stronger opposition to software (and business process) patents: that they almost never truly fit the ideal conceptual model of what patents are supposed to be. Software patents have largely been issued without adequate expertise and understanding by the USPTO of how software is created and what actually constitutes originality and real invention, so many are conceptually weak. If you "assist" the patent process by explaining how trivially derivative the "invention" was based on lots of prior art, you may kill the whole thing.
And yes, you probably could be fired for that too, but if you are careful and make it clear that you are just being conscientious about keeping the company from wasting effort on a doomed patent, that's not so likely. If you approach it as a tenet of faith that software patents are bad and wrong and you will have no part of them, you should bring a box to work with you that day to carry out your personal belongings...
Actually, as far as I know, plant based substrates are known as epoxys.
I suggest that you try to get a refund from whatever school tried to teach you organic chemistry
Epoxy resins are formed by the combination of components that are synthesized from fossil fuel sources. The name comes from the C2O "epoxide" ring that is present in one component (usually epichlorhydrin) and survives on both ends of the epoxy polymer.
Plants are the direct source of one of the oldest, most widely used, and widely recycled polymer materials: cellulose and lignin. Plants can be the primary input to processes yielding the short-chain hydrocarbons that are used as the basic ingredients for many plastics, and there have been some processes developed recently that use lignin as the starting point for commercially usable polystyrenes and polyurethanes.
It is useful to keep in mind that all fossil fuels are the result of various sorts of biomass landing in just the right sorts of temperature and pressure conditions by the vagaries of sedimentation and plate tectonics. We know how to replicate those processes in far less time. It doesn't make sense to do so for fuel and as long as the natural stuff has been cheap and plentiful it hasn't made sense as a way to get the raw materials for plastics, but as we work our way towards the increasingly expensive dregs of naturally occurring oil, it will get more competitive to use various sorts of cultivatable life as our industrial starting points.