Oh, hell. I forgot to mention your completely absurd assertation on the other end that normal people work 260 days a year. I mentioned it elsewhere, but not here.
There are only 260 weekdays in a year. At least, on average.
People do not work every day. They get holidays, and vactions.
Basically, you picked the shortest possible amount of time that teachers could possibly be working, the classdays they have to teach, ignoring anything else, and you picked the maximum possible amount of days anyone else could work.
I don't know where the mass stupidity is coming from about 'paid lunch breaks'. I didn't at any point actually call them 'paid lunch breaks'. People on salary don't get 'paid' or 'not paid' for breaks at all, because they are not hourly workers. I said people working 'eight-hour days' work seven hours. This is a fact, it is true, it is not arguable no matter what semantics you want to apply to their lunch. 9-5 is seven hours of work and an hour of not-work.
Whereas teachers are not missing that hour. While the 'law' may indeed say they get it off...they don't. Teachers do not often take 'breaks'. Sometimes they might get to turn their kids over to another teacher for, or relax while watching them at recess or lunch, but most teachers have almost no time where they are not responsible for watching their students, even if they aren't 'teaching'. Even where classes change, teachers often stay in their classrooms helping students and watching those who got their early, or watching students in the hall.
The only time teachers 'really' have a break is when they are in the teacher's lounge. If there are students present, it's not a break. And the average is, indeed, much closer to 30 minutes a day than an hour.
And I have no idea in what universe you live in that students are only at school six hours. They are at school from 8 to 3. That is, tada, seven hours. Sometimes it's 8 to 2:20, but, OTOH, sometimes it's 7:45 to 3:15, like it was in my high school, or 7:30 to 3:00. If you don't believe me, google 'high school bell schedule'.
Hell, my high school had four 1:30 minute class periods the last year. That would be a really neat trick to fit into a six hour day. I guess we just teleported from class to class, and had no lunch or breaks.
At least you admit the two hour padding.
And, BTW, I'm not talking out of my ass. My mother is a school teacher, and rode with her and stayed in her classroom when I was in middle school. She arrived at school every day at 6:45-7, and left at 4, although admittedly she got to leave at 3:20 on Friday when the busses left. And she wasn't being dilligent, she actually had to punch in and out and make up missing time, although I am not exactly sure what her hours were, I do know that sometimes we had to stay late on Friday because she had missed time.
Also, many places do *not* have teachers coming in more than ~180 days.
That is, flatly, a fucking lie. ALL schools in the USA have, as a minimum, 180 days of scheduled education. Maybe there are laws saying they don't have to teach more than 180-182 days, which is nice, but that doesn't mean they aren't working other days.
You are operating on the assumption they didn't really mean to spend that much.
It's entirely possibly they capped at, say, 500 dollars a day (Remember, this was over 5 years.), and did so, which is about 900,000 dollars.
Then they went and looked and figured out that roughly half those were fraudulent, and thus kept their ad from running the rest of the day. Hence, they want half their money back.
Of course, this entire thing is bogus, but while the idea that they didn't know they were spending that much is indeed insane, no business could operate like that, but nothing requires that to be true for them to have a case.
WRT your sub situtation, that's really nice, but it's certainly not normal. Sometimes, rarely, subs will be covered for sickdays, but I've honestly never heard of them being covered for a personal day.
Anyway, people don't get paid for 'lunch hour'. They are on salary, they don't get paid for any hour of work. I was just pointing out that an 'eight hour day' is actually seven hours.
I was comparing the time spent teaching to other salaried jobs, because of the insane assertation that you needed to multiple teacher salaries by 30% to 'normalize' them.(1) The only way to do that is to figure out how many hours a day people are expected to be present and working.
In a standard 9-5 job, that's 7 hours. In teaching, that's 8.75 or so.
And I just realized that I got scammed. Not only is 180 too low for teachers, which I caught, 260 is obviously too high.(2) There is an average of 260.89 total weekdays in a year, period. (365.25*5/7) People do not work every day.(2)
Let's call it 250 instead of 260, which is assuming one week of vacation and only five holidays.
250 days x 7 hours is 1750.
200 days x 8.75 hours is 1750.
Well, damn. Look at that. I actually did pick 250 before doing the math. And 250 is probably too high, but I'll continue to err on the side of caution because it's funnier when the amounts are identical.
1) That entire concept is actually a little dodgy. Teachers have to live 365 days a year, no matter when they work, and it is non-trivial to get and keep a job in the two summer months, every year, unless they live somewhere there is summer tourism...and then they end up competing with all their students for work. You can't be a teacher 80% of the year and a legal aide, or whatever, the other 20%. How much an employer wants to pay may be how much value they get out of the worker, but how much a worker wants to be paid is how much they value other activities they could have been doing instead of that job, including other jobs that would have made more money. This is called 'opportunity costs', and is how people value their time. They may not have to do any 'work' during summer break, but they can't do 'whatever they want', because they can't hold down a two month job, so they do have losses those months, and will want to paid for them.
2) In fact, it's SO obviously wrong that it makes me suspect it's delibrately wrong. Only a complete and utter fool would think 'normal people work every single weekday' and 'teachers work only the amount of days specificed by law that classes must be scheduled for students'. Ignorance about teachers could lead you to a second mistake, but not the first. Only a complete and utter fool, or someone who wanted to lie and claim that 'teachers are underpaid' is a myth, would claim the first.
A traditonal eight hour day has these hours in it:
9-10
10-11
11-12
12-1
1-2
2-3
3-4
4-5
That is a 9-5 workday. It has a traditionally has an hour long lunch break, usually starting sometime after 11 and ending before 2. Seven hours of work. Sometimes it's 40 minutes for lunch, and 10 minutes each for two breaks, but an eight hour day is roughly seven hours of work.
OTOH, often teachers don't get any lunch break, because they sit down with, eat with, and have to watch, their kids. Some places, very few, might have staff to manage the lunchroom, but that is not normal. And they might get a P.E. break every week, or an art break, or something, for thirty minutes, and in the higher grades they instead get the same breaks as students.
But no matter how you measure it, teachers tend to be required to work at least an extra hour and half a day vs. the normal 40 hour a week employees, and don't 'volunteer' less.
That's ignoring any extra work either of those people might do outside of 'required', but teachers tend to do as much as anyone else in that respect.
The real 'myth' here that is being propagated is that teachers work less than other people, and should be paid less. They might work a month and half less, but they work the equivalent of a 48-hour week. Comparing the 'days' someone works leads to insane things. Someone who works 4 12-hour shifts at Waffle House a week isn't slacking off because they're working four days a week. And someone who works 4 hours a day every day has a part-time job. (Erm, legally, that's 28 hours, and a part-time job is 27 hours or less, but you get the point.)
The only thing you can use to compare yearly salaries is 'amount of hours they are required to be on the job that year'.
And this entire thing has been one huge lie, because teacher actually are required to be on the job the entire time they working, whereas quite a lot of white-collar workers can slack off for thirty minutes without anyone giving them the slightest bit of notice.
I don't know where you got your numbers from, but 180 days is an absurd estimate for teachers.
180 days is, in most states, the set amount for students. Teachers have at least five days post- and five days pre-planning (Many teachers just sit around in their room, because they aren't idiots and did a lot of their work in advance. But they have to be there, and they have meetings they have to go to.), and tend to come in a day early and sometimes leave a day late for Christmas and have other work days, so the actual amount of required showing up is probably closer to 195 days of work. Throw in another 5 days for workshops and recertification test to even it out to 200 or so.
And, um...you've apparently forgotten that teachers tend to work, roughly, from 7:00 to 4, or 6:45 to 3:45, or whenever the school operates, which is an hour longer than 9 to 5. They have roughly seven hours of students, and about two hours of padding, and, yes, they are actually required to be there during that time.
260 days x 8 hours is 2080.
200 days x 9 hours is 1800.
Oh, wait. I screwed up. You see, teachers don't get lunch breaks, or, at least, not hour long ones. Sometimes they get a 20 minute reprieve form the kids, sometimes not, so let's call it a 15 minutes average, to make the math nice, although I suspect it's lower.
260 days x 7 hours is 1820.
200 days x 8.75 hours is 1750.
Well, damn. Look at that. A 4% difference. Might I suggest that teachers are slightly less likely to be able to slack off during the day without anyone noticing, and thus that 4% isn't really 'less work'?
So teachers don't actually work less than people who work 11 months a year, they work about the same amount. They just do it in 10 months instead. Padding the numbers by 30% is completely insane.
Oh, wait. Forgot one thing. Teachering is the only salaried job that, when you call in sick, you have to pay for a replacement.
I wouldn't be the slightest bit surprised if the number of 'external' OO hackers, ones without access to some sort of compile server, numbered less than 10.
OO takes way too long to compile, and it's not helped by the fact you have to compile the whole damn thing.
Bad hardware cannot hurt the OS, unless it starts randomly flooding memory with gibberish via DMA, or toggles random bus lines or something. This is because the OS does not talk to the hardware, it talks to drivers.
Bad drivers hurt the OS. Drivers that do not hide flaws in hardware (Which is their job.) or, more often, simply the drivers are bad themselves, and the hardware is fine.
No, it means one where a company uses its monopoly position to say 'We're not going to write drivers for your software, you have to do it, or no one can use your hardware' will get exactly the kind of drivers you'd expect hardware companies to produce. Pawning the driver production onto the hardware companies was possibly the stupidest idea ever.
Linux does not have this problem, even though Linux supports at least one order of magnitude more hardware that Windows, because Linux drivers are written by the kernel team, or at least go through them before getting to the users. This support includes a lot of really flakey crap. As long as it is consistently flakey in a known way, the drivers can work around this.
Yes, Linux gets most hardware support later, and some never at all, like certain WinModems, which was probably exactly what MS wanted with its power play (Although it was probably aimed at OS/2), but I suspect they didn't fully logic out the fact that hardware manufacturers have very little incentive to spend a lot of money on making good drivers, because people don't see 'my mouse driver' crash, they see Windows crash.
This is part of what MS certification on driver is attempting, but it's completely unworkable they way they're trying to do it. To hold drivers up to a standard of quality, they really need to be writing them in the first place.
In short, MS's problem with hardware is entirely of its own making, even though the drivers are written by other companies. People who write real OSes write the drivers. (In fact, real OSes mostly are drivers, some sort of interface, some utility programs, and a bunch of libraries.)
That thing besides IRC that you mentioned is about the only way to get complete albums, and mostly the only way to get rare and bootleg stuff, although there are a few obscure p2p places too.
There might be a tiny bit of infringement that lyrics are enabling. People might download them and perform their works without compensation.
Of course, anyone who can copy the music by ear can probably copy the lyrics too. Or they could buy the sheet music and no performance rights.
Meanwhile, these 'illegal' covers are promoting the original band, and if the cover band gets big, they'll purchase the rights, or someone will catch on.
Of course, if the theory is, without printed music, no one can ever sing the music, they've just shot themselves in the torso. Because, if that were true, no one would ever buy performance rights, because they don't know how well they can sing the damn song.
I am not a musician, but I am sure that every single person who has ever paid to sing someone's song has first attempted singing it at least once before paying for it, if only to themselves. Probably many times. It would be really stupid to pay for the rights to sing it, and then discover that they don't really like it.
Hell, at least going after bands who sing, and get paid for, cover versions, makes some sense. It might, indeed, be counter-productive in the long run, but it makes sense in the short term: If you want to sing covers, you pay for the rights to perform the music.
In the long run, there is a good deal more evidence that hearing a cover of 'Tainted Love' illegally performed in a bar somewhere will cause you to buy than MP3s will. Their shortsightedness and attempt to retain control of their artists are causing them to shoot themselves in the foot, but at least they have some reason for it.
Whereas this 'lyrics' crackdown would render one thing impossible: Searching for the name and artist of a song.
Without the name and artist, WE CAN'T BUY THE DAMN SONG.
They may not care if we can sing along to a song or not, by looking up the lyrics from the name and artist, but surely someone would go 'Hey, wait. We still need to let people look things up in the other direction.'
But that's gibberish. If you're looking for the name and artist, you aren't going to page through all the sheets to find them.
And if you are, there is absolutely no reason to then buy the sheet music. You have learned what you were trying to learn the second you find the right sheet.
So all you're doing is wasting everyone's time. They still wouldn't get any money.
The only way they'd make money is, as you suggest, people who wanted to learn the name and artist just went down and purchases sheets randomly, without looking at them, until they hit on the right one. That does not seem like a very likely plan of action.
In what crazy-ass universe does lyrics cut into sales of anything?
People who 'legitimately' need them, people who are singing cover versions or whatever, already are paying for them when they pay for the rights to sing the song, or they're already outlaws and cracking down on the lyrics won't help anything.
Everyone else gets them for two reason: To figure out the name and singer of a song, so they can get it, or to figure out the words to a song they already have.
The FTP ISN'T FUCKING IMPORTANT. I was just making a point that sometimes what people think of as 'protocol state' is just 'two ends storing random information', and not part of the protocol. And what I described is completely legal for FTP to do. No server would, because that would be extremely stupid. It is, however, legal, because 'current directory' isn't specified as part of the protocol. Commands to set it and change it? Yes. Any requirements about this 'current directory or dataset' beyond accepting those commands? Nope.
The way to prove it wouldn't be legal is trivial: Quote the part of the RFC that says it isn't. But I've read the RFC and it is completely silent on what passed 'directories' mean, so much that it even recognizes they might not be directories. It has some ideas on what they could mean, but refuses to even promote them to the level of SHOULD.
And you almost grasp the idea of HTTP having state, by realize that FTP is connection-oriented. That is how it associates state with a specific entity.
Then you utterly fail to realize that there are other ways of keeping track of state besides the TCP/IP connection. This is rather obvious when you think about UDP protocols, like instant messaging ones, but somehow it keeps eluding you. State is merely the ability to tie incoming data to a specific entity the server has talked to before. Nothing more, nothing less. Some protocols require this, some protocols merely allow it, and some protocols have never heard of it, like DNS. (Technically, all protocols that use TCP require it on the TCP level for the duration of the connection, but that is provided by TCP and hence is not specificed in the protocol.)
And, incidentally, FTP is a rather hilarious example of tying state to the TCP/IP connection, considering FTP requires, duh, extra connections that also have that state. And which can persist after the control channel is logged out.
No. I'm sorry, but what you're saying is craziness.
I am not, at all, confusing application and protocol layer. (Whatever the 'protocol' layer is.)
However, quite a few people seem to be confusing the transport layer and the session layer. The fact the transport layer might disconnect and reconnect does not make the session layer not exist. And there is a reason the session layer is higher than the transport layer, because a specific session might have more than one connection. (As FTP does, in fact.)
And I'm merely pointing out that while HTTP Cookies are a convention to store random state, so are directory paths in FTP. PWD and CWD are exactly identical to Cookie and SetCookie2. One end says to the other some random stuff, and the other is ready to hand that back out, but the actual content is not defined anywhere. It might be a directory path, it might be a session key, it might be a lot of things. But is not really important, I was just pointing out that protocols often have less state than people think.
What is important is that all state is maintained inside applications with TCP/IP. There is no TCP/IP/HTTP that specifies special packets for HTTP. It's normal TCP/IP, handed off to an application, and the application figures out what state it should have. Sometimes that's via what TCP/IP connection it is, sometimes it's not. (Even with FTP, it's sometimes not, as FTP requires extra connections besides the data channel.)
There is certainly a confusion of the layers going on here, but it's by people who've decided that 'real' state==a single TCP/IP connection, when that makes no sense, and is explicitedly denied by the ISO model of layers. (Hey, don't look at me, I didn't bring up 'layers', as they almost always confuse any conversation they are in.)
And the first person to claim that the 'session layer' is part of TCP/IP, and thus not part of any protocols that use TCP/IP, gets a kick in the head. Unless you have no network experience, you know that parts of layers repeat, and that while TCP/IP goes up to session layer, protocols on top of TCP/IP tend to rewind back to transport layer to redefine how to talk to each other, for example, what commands and response codes should be. Some, like p2p apps, even go back down to the network layer and route data.
First of all, 'directories' in FTP are not required to be directories at all. The RFC specifically says they can be 'datasets'. The RFC operates mostly on the assumption they are directories, but they do not have to be.
And, yes, it is 100% legal to randomly change CWD out from under the client, as there is nothing in the RFC banning anyone from doing so. But more to the point, there is nothing requiring where the client thinks it is to match up to where the server thinks the client is. This is actually a specific problem as recognized in the RFC.
As for 'it', I was rather obviously talking about the server, and not talking about logins at all, but associating state data with the people it belongs to. Logins do not keep track of state, logins are state data, and stored just like whether or not you want binary or ascii transfers.
The FTP server's state is tied to the TCP/IP connection, and holds who you logged in as. This is rather obvious...if you login twice, what you do in one session does not affect the other, except in the obvious case of file system alterations. Because you have two TCP/IP connections.
Whereas the HTTP server's state is tied to the HTTP cookie, and holds whatever people choose to put into it. Web pages can put into the state anything the web server knows about the end user, including data they sent by forms, which obviously can include 'login' data. It is much more manual, but much more flexible, allowing, for examle, multiple states to be associated with one user, a web page pulling up whatever one they want.
And the claim that 'HTTP' doesn't understand cookies is, basically, a complete and utter lie. Cookies are defined quite well in RFC 2965, using a header to extent the HTTP protocol, as laid out in RFC 2616. Pretending it's not 'real' because it's in a different RFC is a bit absurd. By that logic SMTP doesn't have authentication.
How they did it was stupid. They had an ActiveX object, and did weird-ass things like connect datasources to controls without any Javascript, neither of which is a very good idea. It was a typical MS lock-in attempt.
It's just, coders at other browsers said 'Hey, you know, that 'get and send XML data asychronously in and out of javascript' is kinda cool idea, let's add a way to do that too'. And they did, and it was made part of the standard, and webpages actually started using it.
It is a pretty nice, and incredibly useful extension to Javascript, and MS deserves credit for it, even if their first implimentation was somewhat crummy (Their whole 'activex' thing is somewhat crummy.) and it was their typical emprace-and-extend stuff. (I mean, iframes were the same thing, and those are nice too.)
Of course, it wouldn't exist at all without client-side scripting, which is a Netscape invention.;)
The article is a spoof, and that's absolutely not true anyway.
Web 'applications' keeps getting used loosely here. An image gallery, unlike what was suggested a few posts back, is not an application.
However, the management interface of that image gallery could be one, where you change the order and add and delete images. There is absolutely no reason to bookmark in that, either, or be able to go 'back'. (Back where? Back to before you deleted that image? Is this a time machine now, where the data in the system depends on where you are in your history?)
If this is still confusing to people: Imagine this 'application' not on the net. Would it be a program where you open things up and manipulate them, like Excel, or a file manager? Is the purpose to manipulate data?
Or is it single use only, like an IM window, where the data shows up and goes away? Or a virus scanner, where you can't logically go to the 'middle' or 'end' of the data, because the data is new each time?
If not any of those, it's not a 'application', and there's no reason in hell to use AJAX.
Or is it more like a help file? Where you can certainly search, and do all sorts of stuff, but in the end, it's just people looking at data. That's not an application. It's 'just' a web site. (I say 'just' because, while it might be less 'cool', the data it provides is useful to more people total than a 'application' is.)
If the manipulation is limited to certain people, like admin, or a few unique circumstances or areas, like a CMS or a complicated preferences page or a chat box in a random site, then, by all means, use AJAX there, but keep the other pages normal.
You do realize that AJAX can be done in PHP, right?
AJAX is just a web page that use asynchronous javascript to communicate with the server via XML.
The client side is always Javascript. The server side can be any language that speaks XML, which is basically every one of them. (And generating XML output from a language that doesn't support it is hardly rocket science.)
But only if you ignore the fact that protocols rarely maintain any state.
For example, FTP. A stateful protocol, right? You move around in directories and whatnot.
Except the server remembers where 'you' are, your directory, but that isn't part of the 'procotol' by any means. Your client hopefully is trying to keep track of where you are, and the server is keeping track of where you are, but these do not have to be the same places, and technically the FTP server could leap you randomly to a different directory, on its end, every two seconds.
The only difference is, with FTP, it knows who 'you' are based on your TCP/IP socket, whereas in HTTP it uses cookies. There are advantages and disadvantages to each method. FTP is more secure in that it's near impossible to hijack other people's TCP/IP connections (Ignoring the whole 'plaintext password' issue specifically with FTP.), but HTTP rocks in that you can stay 'logged in'.
Anyway, the difference between 'stateful' and 'stateless' is not the absolute people seem to think.
At one end, a 'most stateful' protocol would never even let you log out. You are who you are, period, and the server knows that forever, even between shutdowns and reboots. Imagine a serial terminal hooked to a server. You can't ever stop being that terminal.
At the other end, a 'most stateless' protocol would send a single packet in response to a packet, and then forget about you. DNS actually is this.
Most end-user things have some sort of middle ground, where 'state' exists as long as needed, and then is discarded on the command of either end. This state may or may not be tied directly to a TCP/IP socket. Sometimes a protocol is designed as tied to a socket, and then 'upgraded' to allow disconnect/reconnect, like HTTP cookies, or 'screen' which lets you keep remote state while logged out, or FTP resumes, which let you restore a very limited state, specifically where in the file you are.
Slashdot Mirror
There are only 260 weekdays in a year. At least, on average.
People do not work every day. They get holidays, and vactions.
Basically, you picked the shortest possible amount of time that teachers could possibly be working, the classdays they have to teach, ignoring anything else, and you picked the maximum possible amount of days anyone else could work.
Whereas teachers are not missing that hour. While the 'law' may indeed say they get it off...they don't. Teachers do not often take 'breaks'. Sometimes they might get to turn their kids over to another teacher for, or relax while watching them at recess or lunch, but most teachers have almost no time where they are not responsible for watching their students, even if they aren't 'teaching'. Even where classes change, teachers often stay in their classrooms helping students and watching those who got their early, or watching students in the hall.
The only time teachers 'really' have a break is when they are in the teacher's lounge. If there are students present, it's not a break. And the average is, indeed, much closer to 30 minutes a day than an hour.
And I have no idea in what universe you live in that students are only at school six hours. They are at school from 8 to 3. That is, tada, seven hours. Sometimes it's 8 to 2:20, but, OTOH, sometimes it's 7:45 to 3:15, like it was in my high school, or 7:30 to 3:00. If you don't believe me, google 'high school bell schedule'.
Hell, my high school had four 1:30 minute class periods the last year. That would be a really neat trick to fit into a six hour day. I guess we just teleported from class to class, and had no lunch or breaks.
At least you admit the two hour padding.
And, BTW, I'm not talking out of my ass. My mother is a school teacher, and rode with her and stayed in her classroom when I was in middle school. She arrived at school every day at 6:45-7, and left at 4, although admittedly she got to leave at 3:20 on Friday when the busses left. And she wasn't being dilligent, she actually had to punch in and out and make up missing time, although I am not exactly sure what her hours were, I do know that sometimes we had to stay late on Friday because she had missed time.
Also, many places do *not* have teachers coming in more than ~180 days.
That is, flatly, a fucking lie. ALL schools in the USA have, as a minimum, 180 days of scheduled education. Maybe there are laws saying they don't have to teach more than 180-182 days, which is nice, but that doesn't mean they aren't working other days.
You are operating on the assumption they didn't really mean to spend that much.
It's entirely possibly they capped at, say, 500 dollars a day (Remember, this was over 5 years.), and did so, which is about 900,000 dollars.
Then they went and looked and figured out that roughly half those were fraudulent, and thus kept their ad from running the rest of the day. Hence, they want half their money back.
Of course, this entire thing is bogus, but while the idea that they didn't know they were spending that much is indeed insane, no business could operate like that, but nothing requires that to be true for them to have a case.
Anyway, people don't get paid for 'lunch hour'. They are on salary, they don't get paid for any hour of work. I was just pointing out that an 'eight hour day' is actually seven hours.
I was comparing the time spent teaching to other salaried jobs, because of the insane assertation that you needed to multiple teacher salaries by 30% to 'normalize' them.(1) The only way to do that is to figure out how many hours a day people are expected to be present and working.
In a standard 9-5 job, that's 7 hours. In teaching, that's 8.75 or so.
And I just realized that I got scammed. Not only is 180 too low for teachers, which I caught, 260 is obviously too high.(2) There is an average of 260.89 total weekdays in a year, period. (365.25*5/7) People do not work every day.(2)
Let's call it 250 instead of 260, which is assuming one week of vacation and only five holidays.
250 days x 7 hours is 1750.
200 days x 8.75 hours is 1750.
Well, damn. Look at that. I actually did pick 250 before doing the math. And 250 is probably too high, but I'll continue to err on the side of caution because it's funnier when the amounts are identical.
1) That entire concept is actually a little dodgy. Teachers have to live 365 days a year, no matter when they work, and it is non-trivial to get and keep a job in the two summer months, every year, unless they live somewhere there is summer tourism...and then they end up competing with all their students for work. You can't be a teacher 80% of the year and a legal aide, or whatever, the other 20%. How much an employer wants to pay may be how much value they get out of the worker, but how much a worker wants to be paid is how much they value other activities they could have been doing instead of that job, including other jobs that would have made more money. This is called 'opportunity costs', and is how people value their time. They may not have to do any 'work' during summer break, but they can't do 'whatever they want', because they can't hold down a two month job, so they do have losses those months, and will want to paid for them.
2) In fact, it's SO obviously wrong that it makes me suspect it's delibrately wrong. Only a complete and utter fool would think 'normal people work every single weekday' and 'teachers work only the amount of days specificed by law that classes must be scheduled for students'. Ignorance about teachers could lead you to a second mistake, but not the first. Only a complete and utter fool, or someone who wanted to lie and claim that 'teachers are underpaid' is a myth, would claim the first.
9-10
10-11
11-12
12-1
1-2
2-3
3-4
4-5
That is a 9-5 workday. It has a traditionally has an hour long lunch break, usually starting sometime after 11 and ending before 2. Seven hours of work. Sometimes it's 40 minutes for lunch, and 10 minutes each for two breaks, but an eight hour day is roughly seven hours of work.
OTOH, often teachers don't get any lunch break, because they sit down with, eat with, and have to watch, their kids. Some places, very few, might have staff to manage the lunchroom, but that is not normal. And they might get a P.E. break every week, or an art break, or something, for thirty minutes, and in the higher grades they instead get the same breaks as students.
But no matter how you measure it, teachers tend to be required to work at least an extra hour and half a day vs. the normal 40 hour a week employees, and don't 'volunteer' less.
That's ignoring any extra work either of those people might do outside of 'required', but teachers tend to do as much as anyone else in that respect.
The real 'myth' here that is being propagated is that teachers work less than other people, and should be paid less. They might work a month and half less, but they work the equivalent of a 48-hour week. Comparing the 'days' someone works leads to insane things. Someone who works 4 12-hour shifts at Waffle House a week isn't slacking off because they're working four days a week. And someone who works 4 hours a day every day has a part-time job. (Erm, legally, that's 28 hours, and a part-time job is 27 hours or less, but you get the point.)
The only thing you can use to compare yearly salaries is 'amount of hours they are required to be on the job that year'.
And this entire thing has been one huge lie, because teacher actually are required to be on the job the entire time they working, whereas quite a lot of white-collar workers can slack off for thirty minutes without anyone giving them the slightest bit of notice.
People with money, and people with power, like the government, don't have to obey the law unless they want to.
180 days is, in most states, the set amount for students. Teachers have at least five days post- and five days pre-planning (Many teachers just sit around in their room, because they aren't idiots and did a lot of their work in advance. But they have to be there, and they have meetings they have to go to.), and tend to come in a day early and sometimes leave a day late for Christmas and have other work days, so the actual amount of required showing up is probably closer to 195 days of work. Throw in another 5 days for workshops and recertification test to even it out to 200 or so.
And, um...you've apparently forgotten that teachers tend to work, roughly, from 7:00 to 4, or 6:45 to 3:45, or whenever the school operates, which is an hour longer than 9 to 5. They have roughly seven hours of students, and about two hours of padding, and, yes, they are actually required to be there during that time.
260 days x 8 hours is 2080.
200 days x 9 hours is 1800.
Oh, wait. I screwed up. You see, teachers don't get lunch breaks, or, at least, not hour long ones. Sometimes they get a 20 minute reprieve form the kids, sometimes not, so let's call it a 15 minutes average, to make the math nice, although I suspect it's lower.
260 days x 7 hours is 1820.
200 days x 8.75 hours is 1750.
Well, damn. Look at that. A 4% difference. Might I suggest that teachers are slightly less likely to be able to slack off during the day without anyone noticing, and thus that 4% isn't really 'less work'?
So teachers don't actually work less than people who work 11 months a year, they work about the same amount. They just do it in 10 months instead. Padding the numbers by 30% is completely insane.
Oh, wait. Forgot one thing. Teachering is the only salaried job that, when you call in sick, you have to pay for a replacement.
OO takes way too long to compile, and it's not helped by the fact you have to compile the whole damn thing.
Bad drivers hurt the OS. Drivers that do not hide flaws in hardware (Which is their job.) or, more often, simply the drivers are bad themselves, and the hardware is fine.
Linux does not have this problem, even though Linux supports at least one order of magnitude more hardware that Windows, because Linux drivers are written by the kernel team, or at least go through them before getting to the users. This support includes a lot of really flakey crap. As long as it is consistently flakey in a known way, the drivers can work around this.
Yes, Linux gets most hardware support later, and some never at all, like certain WinModems, which was probably exactly what MS wanted with its power play (Although it was probably aimed at OS/2), but I suspect they didn't fully logic out the fact that hardware manufacturers have very little incentive to spend a lot of money on making good drivers, because people don't see 'my mouse driver' crash, they see Windows crash.
This is part of what MS certification on driver is attempting, but it's completely unworkable they way they're trying to do it. To hold drivers up to a standard of quality, they really need to be writing them in the first place.
In short, MS's problem with hardware is entirely of its own making, even though the drivers are written by other companies. People who write real OSes write the drivers. (In fact, real OSes mostly are drivers, some sort of interface, some utility programs, and a bunch of libraries.)
That thing besides IRC that you mentioned is about the only way to get complete albums, and mostly the only way to get rare and bootleg stuff, although there are a few obscure p2p places too.
There might be a tiny bit of infringement that lyrics are enabling. People might download them and perform their works without compensation.
Of course, anyone who can copy the music by ear can probably copy the lyrics too. Or they could buy the sheet music and no performance rights.
Meanwhile, these 'illegal' covers are promoting the original band, and if the cover band gets big, they'll purchase the rights, or someone will catch on.
Of course, if the theory is, without printed music, no one can ever sing the music, they've just shot themselves in the torso. Because, if that were true, no one would ever buy performance rights, because they don't know how well they can sing the damn song.
I am not a musician, but I am sure that every single person who has ever paid to sing someone's song has first attempted singing it at least once before paying for it, if only to themselves. Probably many times. It would be really stupid to pay for the rights to sing it, and then discover that they don't really like it.
In the long run, there is a good deal more evidence that hearing a cover of 'Tainted Love' illegally performed in a bar somewhere will cause you to buy than MP3s will. Their shortsightedness and attempt to retain control of their artists are causing them to shoot themselves in the foot, but at least they have some reason for it.
Whereas this 'lyrics' crackdown would render one thing impossible: Searching for the name and artist of a song.
Without the name and artist, WE CAN'T BUY THE DAMN SONG.
They may not care if we can sing along to a song or not, by looking up the lyrics from the name and artist, but surely someone would go 'Hey, wait. We still need to let people look things up in the other direction.'
And if you are, there is absolutely no reason to then buy the sheet music. You have learned what you were trying to learn the second you find the right sheet.
So all you're doing is wasting everyone's time. They still wouldn't get any money.
The only way they'd make money is, as you suggest, people who wanted to learn the name and artist just went down and purchases sheets randomly, without looking at them, until they hit on the right one. That does not seem like a very likely plan of action.
In what crazy-ass universe does lyrics cut into sales of anything?
People who 'legitimately' need them, people who are singing cover versions or whatever, already are paying for them when they pay for the rights to sing the song, or they're already outlaws and cracking down on the lyrics won't help anything.
Everyone else gets them for two reason: To figure out the name and singer of a song, so they can get it, or to figure out the words to a song they already have.
The way to prove it wouldn't be legal is trivial: Quote the part of the RFC that says it isn't. But I've read the RFC and it is completely silent on what passed 'directories' mean, so much that it even recognizes they might not be directories. It has some ideas on what they could mean, but refuses to even promote them to the level of SHOULD.
And you almost grasp the idea of HTTP having state, by realize that FTP is connection-oriented. That is how it associates state with a specific entity.
Then you utterly fail to realize that there are other ways of keeping track of state besides the TCP/IP connection. This is rather obvious when you think about UDP protocols, like instant messaging ones, but somehow it keeps eluding you. State is merely the ability to tie incoming data to a specific entity the server has talked to before. Nothing more, nothing less. Some protocols require this, some protocols merely allow it, and some protocols have never heard of it, like DNS. (Technically, all protocols that use TCP require it on the TCP level for the duration of the connection, but that is provided by TCP and hence is not specificed in the protocol.)
And, incidentally, FTP is a rather hilarious example of tying state to the TCP/IP connection, considering FTP requires, duh, extra connections that also have that state. And which can persist after the control channel is logged out.
I am not, at all, confusing application and protocol layer. (Whatever the 'protocol' layer is.)
However, quite a few people seem to be confusing the transport layer and the session layer. The fact the transport layer might disconnect and reconnect does not make the session layer not exist. And there is a reason the session layer is higher than the transport layer, because a specific session might have more than one connection. (As FTP does, in fact.)
And I'm merely pointing out that while HTTP Cookies are a convention to store random state, so are directory paths in FTP. PWD and CWD are exactly identical to Cookie and SetCookie2. One end says to the other some random stuff, and the other is ready to hand that back out, but the actual content is not defined anywhere. It might be a directory path, it might be a session key, it might be a lot of things. But is not really important, I was just pointing out that protocols often have less state than people think.
What is important is that all state is maintained inside applications with TCP/IP. There is no TCP/IP/HTTP that specifies special packets for HTTP. It's normal TCP/IP, handed off to an application, and the application figures out what state it should have. Sometimes that's via what TCP/IP connection it is, sometimes it's not. (Even with FTP, it's sometimes not, as FTP requires extra connections besides the data channel.)
There is certainly a confusion of the layers going on here, but it's by people who've decided that 'real' state==a single TCP/IP connection, when that makes no sense, and is explicitedly denied by the ISO model of layers. (Hey, don't look at me, I didn't bring up 'layers', as they almost always confuse any conversation they are in.)
And the first person to claim that the 'session layer' is part of TCP/IP, and thus not part of any protocols that use TCP/IP, gets a kick in the head. Unless you have no network experience, you know that parts of layers repeat, and that while TCP/IP goes up to session layer, protocols on top of TCP/IP tend to rewind back to transport layer to redefine how to talk to each other, for example, what commands and response codes should be. Some, like p2p apps, even go back down to the network layer and route data.
What it does not do is undo your last action, which is why AJAX must never be used for page navigation.
And, yes, it is 100% legal to randomly change CWD out from under the client, as there is nothing in the RFC banning anyone from doing so. But more to the point, there is nothing requiring where the client thinks it is to match up to where the server thinks the client is. This is actually a specific problem as recognized in the RFC.
As for 'it', I was rather obviously talking about the server, and not talking about logins at all, but associating state data with the people it belongs to. Logins do not keep track of state, logins are state data, and stored just like whether or not you want binary or ascii transfers.
The FTP server's state is tied to the TCP/IP connection, and holds who you logged in as. This is rather obvious...if you login twice, what you do in one session does not affect the other, except in the obvious case of file system alterations. Because you have two TCP/IP connections.
Whereas the HTTP server's state is tied to the HTTP cookie, and holds whatever people choose to put into it. Web pages can put into the state anything the web server knows about the end user, including data they sent by forms, which obviously can include 'login' data. It is much more manual, but much more flexible, allowing, for examle, multiple states to be associated with one user, a web page pulling up whatever one they want.
And the claim that 'HTTP' doesn't understand cookies is, basically, a complete and utter lie. Cookies are defined quite well in RFC 2965, using a header to extent the HTTP protocol, as laid out in RFC 2616. Pretending it's not 'real' because it's in a different RFC is a bit absurd. By that logic SMTP doesn't have authentication.
In what universe would those be hard to impliment in AJAX?
It's just, coders at other browsers said 'Hey, you know, that 'get and send XML data asychronously in and out of javascript' is kinda cool idea, let's add a way to do that too'. And they did, and it was made part of the standard, and webpages actually started using it.
It is a pretty nice, and incredibly useful extension to Javascript, and MS deserves credit for it, even if their first implimentation was somewhat crummy (Their whole 'activex' thing is somewhat crummy.) and it was their typical emprace-and-extend stuff. (I mean, iframes were the same thing, and those are nice too.)
Of course, it wouldn't exist at all without client-side scripting, which is a Netscape invention. ;)
Web 'applications' keeps getting used loosely here. An image gallery, unlike what was suggested a few posts back, is not an application.
However, the management interface of that image gallery could be one, where you change the order and add and delete images. There is absolutely no reason to bookmark in that, either, or be able to go 'back'. (Back where? Back to before you deleted that image? Is this a time machine now, where the data in the system depends on where you are in your history?)
If this is still confusing to people: Imagine this 'application' not on the net. Would it be a program where you open things up and manipulate them, like Excel, or a file manager? Is the purpose to manipulate data?
Or is it single use only, like an IM window, where the data shows up and goes away? Or a virus scanner, where you can't logically go to the 'middle' or 'end' of the data, because the data is new each time?
If not any of those, it's not a 'application', and there's no reason in hell to use AJAX.
Or is it more like a help file? Where you can certainly search, and do all sorts of stuff, but in the end, it's just people looking at data. That's not an application. It's 'just' a web site. (I say 'just' because, while it might be less 'cool', the data it provides is useful to more people total than a 'application' is.)
If the manipulation is limited to certain people, like admin, or a few unique circumstances or areas, like a CMS or a complicated preferences page or a chat box in a random site, then, by all means, use AJAX there, but keep the other pages normal.
You do realize that AJAX can be done in PHP, right?
AJAX is just a web page that use asynchronous javascript to communicate with the server via XML.
The client side is always Javascript. The server side can be any language that speaks XML, which is basically every one of them. (And generating XML output from a language that doesn't support it is hardly rocket science.)
Everything in moderation...
...including moderation.
But only if you ignore the fact that protocols rarely maintain any state.
For example, FTP. A stateful protocol, right? You move around in directories and whatnot.
Except the server remembers where 'you' are, your directory, but that isn't part of the 'procotol' by any means. Your client hopefully is trying to keep track of where you are, and the server is keeping track of where you are, but these do not have to be the same places, and technically the FTP server could leap you randomly to a different directory, on its end, every two seconds.
The only difference is, with FTP, it knows who 'you' are based on your TCP/IP socket, whereas in HTTP it uses cookies. There are advantages and disadvantages to each method. FTP is more secure in that it's near impossible to hijack other people's TCP/IP connections (Ignoring the whole 'plaintext password' issue specifically with FTP.), but HTTP rocks in that you can stay 'logged in'.
Anyway, the difference between 'stateful' and 'stateless' is not the absolute people seem to think.
At one end, a 'most stateful' protocol would never even let you log out. You are who you are, period, and the server knows that forever, even between shutdowns and reboots. Imagine a serial terminal hooked to a server. You can't ever stop being that terminal.
At the other end, a 'most stateless' protocol would send a single packet in response to a packet, and then forget about you. DNS actually is this.
Most end-user things have some sort of middle ground, where 'state' exists as long as needed, and then is discarded on the command of either end. This state may or may not be tied directly to a TCP/IP socket. Sometimes a protocol is designed as tied to a socket, and then 'upgraded' to allow disconnect/reconnect, like HTTP cookies, or 'screen' which lets you keep remote state while logged out, or FTP resumes, which let you restore a very limited state, specifically where in the file you are.