Have you ever attended a major college? Do you know how much individual time students get with professors? Practicaly zilch. If every student that needed help was assisted by a professor, or for that matter a TA that may or may not know what they're doing, there would never be any actual teaching done.
But do you also want that person to be taught that it's bad to go to others for help?
An exact copy of a program is certainly unacceptable in an academic setting, but going to someone else to get help and coming back with a function they wrote to solve a problem in the assignment is something that should be encouraged, or at the very least, not discouraged.
If you want to make sure your students understand the code they're using, GIVE THEM A TEST.
Don't count on getting an actual useful education, esspecialy since you already have experience. Memorize what they tell you to memorize and then write it on the little peice of paper in different words and hand it to the professor. But do not neccisarily believe anything they tell you that you don't already know.
I've met people with CS degrees that didn't have a clue. They could write C or C++ programs, but they needed strict guidelines, their "skills" essentialy made them word processors. And don't get me started on the CS graduates that don't understand that Windows isn't the ONLY OS out there. (Trust me, they exist, even now)
While it may not have been *wholly* proper, it comes close to my ideal world. It was true, targeted advertising that was unintrusive and informative. Don't beat it up too bad.
Hmmm, I guess I'm "superhuman" then?
I average above 105 all the time, 120 on good days, and over 130 if I'm really trying to get something typed out fast (like in the middle of a game of Quake)
In the back of my mind I'm wondering if the high-capacity 75GXP drives have a defect that makes them more sensitive to being bumped, while off and in transport or otherwise. This could explain why some people run into this and others don't, some people are less careful with their components (then again, I toss around HDD's, procs, etc. rather roughly, so who am I to talk?:)
My 45GB 75GXP drive has been fine since I got it in.... Feburary? March? something like that... the cases I've heard are all "here and there" sorta thing, sounds like the drives either had a couple bad manufacturing runs, or the drives just randomly have a defect, and the rate is higher than for other components.
IBM is a good company now, and they're also a company that doesn't want to lose customers, I'm sure they're looking into this.
It's probably more expensive to manufacture single-button assemblies than two+ buttons, due to simple volume. Generaly, higher volume = lower price, this would likely prove esspecialy true in this case.
Can you clarify this again? -1 is used to return an error? in TIME?
can you provide an example where this would be useful? it's probably just me, but I can't really see a real-world use for it...
My understanding was that "int" was always "short int", though yes, it's entirely possible for this to change between compiliers.
on the bool, yes, I was braindead on that one as far as the bit/byte thing was concerned, as for bool, are you sure only C++ has it? I thought ANSI C had bool
long int bytes, I didn't know this ever varied, I thought it was defined by the standard
time_t typedef, does POSIX not specify that it's a 32bit int? I don't exactly have the cash to order a copy of the standard
last two points:
yes, I ment unsigned, I went over the comment twice and still didn't catch it, oops
for breaking a lot of code written under invalid assumptions, yes, I'm aware this is possible, but that code is arguably already broken and should be fixed. I love backwards compatability when possible, but I'm not a big fan of backwards compatability when it means being retaining compatability with something that has a bug/design flaw.
My own braindeadness on this is partly at fault here.
I've been looking and I'll have to look harder, but because I don't have a full C++ reference guide (I should pick up the book by the C++ creator, the name of the book escapes me at the moment) I might not find its exact size, however I just tested this:
bool returns "1" with any value but "0", so I don't think it's a "normal" type like char, or any of the "standard/normal" ints, so "char" isn't neccisarily a correct replacement for "bool".
Also there have been discussions as to why it was better to impliment bool than to use some alternative.
As for the less-clean solution, an AC already stated the obvious: negative values for time_t are NON-STANDARD. As such, they should be discouraged.
OK sorry, I've never really studied java, and from the conversations I've had with people about it, I was under the impression that java did some sort of dynamic allocation for its ints. Guess they were all just inexperienced:)
Incase someone wants this in a bit plainer english, let me explain. (Thank you, Jesse Liberty)
In C, C++, and probably most other programming languages (I'm not a guru on programming), an integer is either "signed" or "unsigned". They are also either "long" or "short". The reason for the distinctions is primarily memory-related, using a long int (4 bytes) is a waste of memory if you're just going to store say, a number up to 300 in it, in which case a short int would be more appropriate. And if you're only going to store a single byte (such as 1 or 0) there's usualy something like the int type "bool", a 1-byte long int, that allows a 1-byte value to be stored (technicaly this value could be 0 to 9, I'm not sure if negatives are allowed).
An unsigned integer is (rather obviously if you think about it) a positive-only number, you can't have a negative number in an unsigned int (well, you can try, but it'll just wrap around to its maximum value).
an unsigned long int can go from 0 to 4,294,967,295
Now, with time_t, the time is being stored in a signed long int. This can be any value from -2,147,438,648 to 2,147,483,647 (you've just split the area avalible for values between negative and positive) on a 32bit system. Unfortunitely, in 2038, that's no longer enough (DOH!) as the # of seconds from UNIX Epoch will pass the maximum (positive) value of a signed long int, and suddenly our system clocks (on POSIX-compliant, and even some/many non-compliant UNIXish systems) will wrap around to, well, the turn of the century. This is *precisely* what the fear was with Y2K, just further in the future. And this isn't theory based on a couple systems, this is a real fear, because POSIX compliant systems WILL do this. Fortunitely we have ~36 years to solve this problem.
The first solution, and probably the cleanest, is to go to 64bit systems, this transition is just beginning, but personaly I think it will be complete within 30 years... ancient business systems might still have something to worry about (as with Y2K) but I doubt it.
The other, not-as-clean-but-quick-and-simple, solution is to bump the variable holding the time to a signed long int. This could be done by a newbie with a C book, and will allow UNIX time to go to 4,294,967,295, sometime after 2100 (I think it was 2106?). This is a band-aid and doesn't really fix the end problem that what we need is an EFFICIENT dynamicaly allocated int type, but just moving to an unsigned long will buy us time if, for some reason, we haven't fixed these damn problems by 2038.
(I THINK Java has dynamic int variables, but i don't think they're efficient. I'd have to grab an extensive book on Java, and I don't have that kind of time or patience:).
And no, we can't just make infinite-sized variables in our current infrastructure, the first one that got initialized would use all the memory and lock the system:)
The point is that for some reason, signed long ints were used instead of unsigned.
Why they were that braindead, I do not know.
Maybe they needed it to work under negative numbers before the system was activated as production? I'm pretty sure work on UNIX began shortly before 1970.
He wants higher density cages, the one he pointed to is 1 drive per bay, he wants something like the 5 per 3 he pointed to, but all the ones he's found are SCA-only.
Hmmm... I guess you don't read the changelog very closely do you? More fixes and additions go into each new kernel version than you would find in many updates for commercial closed-source software.
With most changes, for example, a driver fix, you don't need to test out the whole kernel, just things that deal specificaly with that driver.
And yes, there are bugs in every "stable" release, there are bugs in every "stable" release of all software.
Go monitor the changelog and the linux-kernel list for a couple weeks, and you'll understand why stable kernels are released within 2-4 weeks of eachother.And no, monitoring the KernelTraffic summaries DOES NOT COUNT as monitoring linux-kernel, far more goes on than KT summarizes.
Slashdot Mirror
Have you ever attended a major college? Do you know how much individual time students get with professors? Practicaly zilch. If every student that needed help was assisted by a professor, or for that matter a TA that may or may not know what they're doing, there would never be any actual teaching done.
But do you also want that person to be taught that it's bad to go to others for help?
An exact copy of a program is certainly unacceptable in an academic setting, but going to someone else to get help and coming back with a function they wrote to solve a problem in the assignment is something that should be encouraged, or at the very least, not discouraged.
If you want to make sure your students understand the code they're using, GIVE THEM A TEST.
Don't count on getting an actual useful education, esspecialy since you already have experience. Memorize what they tell you to memorize and then write it on the little peice of paper in different words and hand it to the professor. But do not neccisarily believe anything they tell you that you don't already know.
I've met people with CS degrees that didn't have a clue. They could write C or C++ programs, but they needed strict guidelines, their "skills" essentialy made them word processors. And don't get me started on the CS graduates that don't understand that Windows isn't the ONLY OS out there. (Trust me, they exist, even now)
While it may not have been *wholly* proper, it comes close to my ideal world. It was true, targeted advertising that was unintrusive and informative. Don't beat it up too bad.
Hmmm, I guess I'm "superhuman" then?
I average above 105 all the time, 120 on good days, and over 130 if I'm really trying to get something typed out fast (like in the middle of a game of Quake)
my only real problem with the big ads, is that they SLOW THE HELL DOWN out of my browser, PLEASE try to find a way around this for the love of god!
One friend of mine played EQ with is wife for a while, I think she might have stopped playing at some point, but played for a while.
:)
Also, www.neriak.com, is run by a husband and wife team, I'd assume that means they both play
In the back of my mind I'm wondering if the high-capacity 75GXP drives have a defect that makes them more sensitive to being bumped, while off and in transport or otherwise. This could explain why some people run into this and others don't, some people are less careful with their components (then again, I toss around HDD's, procs, etc. rather roughly, so who am I to talk? :)
My 45GB 75GXP drive has been fine since I got it in.... Feburary? March? something like that... the cases I've heard are all "here and there" sorta thing, sounds like the drives either had a couple bad manufacturing runs, or the drives just randomly have a defect, and the rate is higher than for other components.
IBM is a good company now, and they're also a company that doesn't want to lose customers, I'm sure they're looking into this.
And I have a now going on 8 year old microsoft busmouse that still works (albeit with some movement hitches sometimes)
It's not just pure volume from a manufacturer, it's volume in the marketplace. The more people making them, the more prices drop.
It's probably more expensive to manufacture single-button assemblies than two+ buttons, due to simple volume. Generaly, higher volume = lower price, this would likely prove esspecialy true in this case.
the generally accepted level at which the human eye ON AVERAGE stops distinguishing FPS, is 60
:P
some people claim they can't see the difference much past 30, and there are a select few people that can tell the difference above 60
and don't get me started on refresh rates
this has been discussed at great length in the past, that is a highly theoretical and VERY conditional situation
OK that clears up the ints, thanks.
:)
:)
I could have sworn I read in at least one credible place that ANSI C had built-in bool, guess not.
POSIX, I just don't know what it days, I should probably try to get some cash together to get a copy of the standard.
Somebody should put the vendors and distributors on alert to have their software changed by 2025
simplest possible form of error reporting gives us a puzzler for 2038...
with 36 years to think about it, I do hope this gets fixed before then
I CAN see the invalid address thing happening, so I suppose it does have some merit keeping it as a signed long... but damn....
Can you clarify this again? -1 is used to return an error? in TIME?
can you provide an example where this would be useful? it's probably just me, but I can't really see a real-world use for it...
My understanding was that "int" was always "short int", though yes, it's entirely possible for this to change between compiliers.
on the bool, yes, I was braindead on that one as far as the bit/byte thing was concerned, as for bool, are you sure only C++ has it? I thought ANSI C had bool
long int bytes, I didn't know this ever varied, I thought it was defined by the standard
time_t typedef, does POSIX not specify that it's a 32bit int? I don't exactly have the cash to order a copy of the standard
last two points:
yes, I ment unsigned, I went over the comment twice and still didn't catch it, oops
for breaking a lot of code written under invalid assumptions, yes, I'm aware this is possible, but that code is arguably already broken and should be fixed. I love backwards compatability when possible, but I'm not a big fan of backwards compatability when it means being retaining compatability with something that has a bug/design flaw.
My own braindeadness on this is partly at fault here.
I've been looking and I'll have to look harder, but because I don't have a full C++ reference guide (I should pick up the book by the C++ creator, the name of the book escapes me at the moment) I might not find its exact size, however I just tested this:
bool returns "1" with any value but "0", so I don't think it's a "normal" type like char, or any of the "standard/normal" ints, so "char" isn't neccisarily a correct replacement for "bool".
Also there have been discussions as to why it was better to impliment bool than to use some alternative.
As for the less-clean solution, an AC already stated the obvious: negative values for time_t are NON-STANDARD. As such, they should be discouraged.
OK sorry, I've never really studied java, and from the conversations I've had with people about it, I was under the impression that java did some sort of dynamic allocation for its ints. Guess they were all just inexperienced :)
By my definition, it became on-topic when people began talking about the 2038 problem in more than a few comments.
Incase someone wants this in a bit plainer english, let me explain. (Thank you, Jesse Liberty)
:)
In C, C++, and probably most other programming languages (I'm not a guru on programming), an integer is either "signed" or "unsigned". They are also either "long" or "short". The reason for the distinctions is primarily memory-related, using a long int (4 bytes) is a waste of memory if you're just going to store say, a number up to 300 in it, in which case a short int would be more appropriate. And if you're only going to store a single byte (such as 1 or 0) there's usualy something like the int type "bool", a 1-byte long int, that allows a 1-byte value to be stored (technicaly this value could be 0 to 9, I'm not sure if negatives are allowed).
An unsigned integer is (rather obviously if you think about it) a positive-only number, you can't have a negative number in an unsigned int (well, you can try, but it'll just wrap around to its maximum value).
an unsigned long int can go from 0 to 4,294,967,295
Now, with time_t, the time is being stored in a signed long int. This can be any value from -2,147,438,648 to 2,147,483,647 (you've just split the area avalible for values between negative and positive) on a 32bit system. Unfortunitely, in 2038, that's no longer enough (DOH!) as the # of seconds from UNIX Epoch will pass the maximum (positive) value of a signed long int, and suddenly our system clocks (on POSIX-compliant, and even some/many non-compliant UNIXish systems) will wrap around to, well, the turn of the century. This is *precisely* what the fear was with Y2K, just further in the future. And this isn't theory based on a couple systems, this is a real fear, because POSIX compliant systems WILL do this. Fortunitely we have ~36 years to solve this problem.
The first solution, and probably the cleanest, is to go to 64bit systems, this transition is just beginning, but personaly I think it will be complete within 30 years... ancient business systems might still have something to worry about (as with Y2K) but I doubt it.
The other, not-as-clean-but-quick-and-simple, solution is to bump the variable holding the time to a signed long int. This could be done by a newbie with a C book, and will allow UNIX time to go to 4,294,967,295, sometime after 2100 (I think it was 2106?). This is a band-aid and doesn't really fix the end problem that what we need is an EFFICIENT dynamicaly allocated int type, but just moving to an unsigned long will buy us time if, for some reason, we haven't fixed these damn problems by 2038.
(I THINK Java has dynamic int variables, but i don't think they're efficient. I'd have to grab an extensive book on Java, and I don't have that kind of time or patience:).
And no, we can't just make infinite-sized variables in our current infrastructure, the first one that got initialized would use all the memory and lock the system
The point is that for some reason, signed long ints were used instead of unsigned.
Why they were that braindead, I do not know.
Maybe they needed it to work under negative numbers before the system was activated as production? I'm pretty sure work on UNIX began shortly before 1970.
should have been "1.5 drives per bay"
He wants higher density cages, the one he pointed to is 1 drive per bay, he wants something like the 5 per 3 he pointed to, but all the ones he's found are SCA-only.
Hmmm... I guess you don't read the changelog very closely do you? More fixes and additions go into each new kernel version than you would find in many updates for commercial closed-source software.
With most changes, for example, a driver fix, you don't need to test out the whole kernel, just things that deal specificaly with that driver.
And yes, there are bugs in every "stable" release, there are bugs in every "stable" release of all software.
Go monitor the changelog and the linux-kernel list for a couple weeks, and you'll understand why stable kernels are released within 2-4 weeks of eachother.And no, monitoring the KernelTraffic summaries DOES NOT COUNT as monitoring linux-kernel, far more goes on than KT summarizes.