Um... feel free to correct me (and I'm sure everyone will leap at the opportunity), but I thought the whole idea of the bill was to ensure that the parents DO get involved. Ie, a child cant go to the video store and buy a NC-17 game (or whatever the classification system is), but instead has to get their PARENTS to buy the game for them.
Otherwise, the kid could just buy the game and hide it until the parents aren't around.
Yes, this is an inconveinece for the store clerks, that have to vet customers ages, and yes it'll reduce sales because there'll be fewer games being sold. But saying that this bill does NOT support a parent's interjection in a child's activities is just stupid.
A business is exempt if they have a business relationship with you. I don't know if that means a 'ongoing' or 'previous' relationship:)
That COULD be the exemption that the author is talking about, in which case their do not call list doesn't seem to be that much different than the one in the US. (I can't read the article right now, though... it's slashdotted).
And... even WITH the exemption, I get remarkably few calls. I've had one from a surveyer who I TOTALLY chewed out for not voluntarily using the list (and I've never heard from them again), and one from a charaty that was VERY apologetic for not using it - they explained that they normally do, but couldn't this time for technical reasons. They seemed sincere, and really wanted to hang up straight away when I mentioned that I'm on the list.
So... what the US has seems to be working, at least for me.
The article is a little off (and, not surprising, given the site it's on).
'cost of creating secrets' is NOT the same as 'cost of keeping secrets'. They're comparing apples to oranges.
Of COURSE creating a secret is more expensive. Because.. you're both creating the information, AND trying to keep it secret. Telling people what you know (revealing the secret) is pittance compared to the time and effort doing the research for something that is to be KEPT secret.
"Internet truths", or the more general form "Media echo chamber". Ie, where the media just echo each other as if it's some kind of truth, rather than doing 'real journalism'.
I'm sure the fact that Konfabulator's 'buy out price' went WAY down after Tiger, and Dashboard, were released has NOTHING, no, NOTHING AT ALL to do with this sale:)
I feel the need to disagree with you on all those points.
I've created several extensions, custom Builders in SCons parlance, with fairly little difficulty.
SCons not only handled traversing multiple directories with ease, it did a MUCH better job doing so than Make provides. in Make, if you have dependencies deep within two distinct directory branches, you have to make one directory depend on the other, making a parallel build bottleneck quite badly. SCons figured out the EXACT dependency itself with no configuration.
The community is pretty active, much more so than some other communities I'm on. No guarantee that they'll be able to solve any particular person's problems, of course.
Agreed that knowing basic python, like how to create an IF structure to create a variant within the SCons configuration files, of example, helps. You certainly don't need to know how to do more advanced Python. However, I've NOT had to look at the SCons source code yet, and the Make structure I converted from was quite complex.
I WILL admit that if you dive in expecting to create a complex build structure as your first project you're going to flounder a little. This is also true of Make and Ant (from what our Ant-using developers tell me). So... just like anything, start simple, or learn to hit the ground running.
I glossed over some of the features, and reasons for them, so let me explain.
The 'md5sum' thing ensures that you're not relying on timestamps. Especially important if you're dealing with several machines that might not have their clocks synchronised perfectly. Furthermore, the 'signature' of any of the build nodes is the concatenation of the MD5s of all it's dependencies, PLUS the command lines to generate that node. Change ANY one of those, including changing any compiler flag, and the signature doesn't match, and the node gets rebuilt.
SCons does its own inherent dependency checking, and caches that, too, plus recording the signatures of all the files needed to generate that information. If any of THAT changes, it will re-get dependencies, and then use the result to determine if a node needs to be rebuilt. This, plus the previous part, makes 'make depend' unnecessary. SCons always gets it right, which cannot be said for Make, or (I think) even Ant... (We currently DO have problems with Ant after a 'cvs update'.). I'm pretty sure that you can make your '.depend' files depend on the files that were used to generate it, but the solution for that for Make (unsure for Ant), is UGLY. SCons handles it all automatically.
SCons also handles cross-platform builds. It's actively tested under *nix and Windows.
Really, if any product deserves to be called a 'category killer' for this category, it isn't Ant, it's SCons.
At this time, pretty damn solid. Yes, it's 'officially' beta, but they're just polishing the edges now.
The only problems I've run into so far relate to SCons being a little too clever for it's own good, and not 'neatly' letting me do things that make could do. I worked around them, once I understood SCons better
For example, SCons lets you generate static and shareable objects using 'StaticObject' and 'SharedObject', and will 'do what's necessary' to make that work on your platform. Eg, under *nix, it will add '-fpic' to SharedObject. It will also refuse to let you add a StaticObject into a SharedLibrary. Which in most cases is just what you'd want to stop happening, but... if you KNOW that in a particular case it will work, then SCons is getting in the way. Eg, we wanted a.a full of.so files that were compiled with -fpic, and then add that whole.a into a.so. Perfectly valid, but odd, and SCon's structure didn't let us do that easily.
But... there's workarounds and they all 'make sense', but require a little more SCons knowledge. The mailing list is quite active and helpful, though.
If your project is straightforward (even if it's HUGE), then there's no problems at all.
Slashdot Mirror
Um... feel free to correct me (and I'm sure everyone will leap at the opportunity), but I thought the whole idea of the bill was to ensure that the parents DO get involved. Ie, a child cant go to the video store and buy a NC-17 game (or whatever the classification system is), but instead has to get their PARENTS to buy the game for them.
Otherwise, the kid could just buy the game and hide it until the parents aren't around.
Yes, this is an inconveinece for the store clerks, that have to vet customers ages, and yes it'll reduce sales because there'll be fewer games being sold. But saying that this bill does NOT support a parent's interjection in a child's activities is just stupid.
And, when all else fails, pick on people's spelling.
ACCEPT != EXCEPT
Yeah... not since the Solaris 10 launch when RedHat had one flying over San Jose that said "Just Another Day at Red Hat".
:)
Awesome!
Clearly, I don't look up often enough.
Perhaps they cost too much around here.
A business is exempt if they have a business relationship with you. I don't know if that means a 'ongoing' or 'previous' relationship :)
That COULD be the exemption that the author is talking about, in which case their do not call list doesn't seem to be that much different than the one in the US. (I can't read the article right now, though... it's slashdotted).
And... even WITH the exemption, I get remarkably few calls. I've had one from a surveyer who I TOTALLY chewed out for not voluntarily using the list (and I've never heard from them again), and one from a charaty that was VERY apologetic for not using it - they explained that they normally do, but couldn't this time for technical reasons. They seemed sincere, and really wanted to hang up straight away when I mentioned that I'm on the list.
So... what the US has seems to be working, at least for me.
Sun are really tooting their horn on this one. They paid for (presumably) a aircraft-towed banner to fly around the SF Bay today.
:)
Haven't seen one of those in ages
My attention span isn't that long :)
Gmail is beta.
:)
Gmail does not have guaranteed uptime.
You do not pin your companies communications system on something you cannot sign a SLA agreement with.
need I go on?
The article is a little off (and, not surprising, given the site it's on).
'cost of creating secrets' is NOT the same as 'cost of keeping secrets'. They're comparing apples to oranges.
Of COURSE creating a secret is more expensive. Because.. you're both creating the information, AND trying to keep it secret. Telling people what you know (revealing the secret) is pittance compared to the time and effort doing the research for something that is to be KEPT secret.
Sheesh!
That's just fine. Because it only has to be done ONCE, and then the information on how to do it will be public knowledge.
"Internet truths", or the more general form "Media echo chamber". Ie, where the media just echo each other as if it's some kind of truth, rather than doing 'real journalism'.
I think I called it just fine. So... 'thptt' to all my detractors! :)
Why? Because the story exerpt above set off the usual bunch of bullshit flags, and the FAQ pointed to did not.
That's why.
Cheap, not free. Cheap.
Ah yes... the old "The best way to get rid of a bad law is to enforce it." gambit.
The problem is: it takes too long, and too many people get hurt along the way. I think it's time for a civil revolt NOW... oh, wait...
I read the article.
:)
I've never seen a more PR-fluff article in my life.
(Okay, that was an exaggeration. I follow the SCO saga as much as the next guy
Wrong? My body IS made of twinkies??
Don't let my room-mates find out. I'm a dead man.
New Metro PCS for bigheads(tm)... talk all you want!
I'd like to point out that this comment did NOT deserve a "(Score:5, Interesting)"
:)
3 at the most, really
I'm sure the fact that Konfabulator's 'buy out price' went WAY down after Tiger, and Dashboard, were released has NOTHING, no, NOTHING AT ALL to do with this sale :)
Fine! Answered! :)
I feel the need to disagree with you on all those points.
I've created several extensions, custom Builders in SCons parlance, with fairly little difficulty.
SCons not only handled traversing multiple directories with ease, it did a MUCH better job doing so than Make provides. in Make, if you have dependencies deep within two distinct directory branches, you have to make one directory depend on the other, making a parallel build bottleneck quite badly. SCons figured out the EXACT dependency itself with no configuration.
The community is pretty active, much more so than some other communities I'm on. No guarantee that they'll be able to solve any particular person's problems, of course.
Agreed that knowing basic python, like how to create an IF structure to create a variant within the SCons configuration files, of example, helps. You certainly don't need to know how to do more advanced Python. However, I've NOT had to look at the SCons source code yet, and the Make structure I converted from was quite complex.
I WILL admit that if you dive in expecting to create a complex build structure as your first project you're going to flounder a little. This is also true of Make and Ant (from what our Ant-using developers tell me). So... just like anything, start simple, or learn to hit the ground running.
I glossed over some of the features, and reasons for them, so let me explain.
The 'md5sum' thing ensures that you're not relying on timestamps. Especially important if you're dealing with several machines that might not have their clocks synchronised perfectly. Furthermore, the 'signature' of any of the build nodes is the concatenation of the MD5s of all it's dependencies, PLUS the command lines to generate that node. Change ANY one of those, including changing any compiler flag, and the signature doesn't match, and the node gets rebuilt.
SCons does its own inherent dependency checking, and caches that, too, plus recording the signatures of all the files needed to generate that information. If any of THAT changes, it will re-get dependencies, and then use the result to determine if a node needs to be rebuilt. This, plus the previous part, makes 'make depend' unnecessary. SCons always gets it right, which cannot be said for Make, or (I think) even Ant... (We currently DO have problems with Ant after a 'cvs update'.). I'm pretty sure that you can make your '.depend' files depend on the files that were used to generate it, but the solution for that for Make (unsure for Ant), is UGLY. SCons handles it all automatically.
SCons also handles cross-platform builds. It's actively tested under *nix and Windows.
Really, if any product deserves to be called a 'category killer' for this category, it isn't Ant, it's SCons.
At this time, pretty damn solid. Yes, it's 'officially' beta, but they're just polishing the edges now.
.a full of .so files that were compiled with -fpic, and then add that whole .a into a .so. Perfectly valid, but odd, and SCon's structure didn't let us do that easily.
The only problems I've run into so far relate to SCons being a little too clever for it's own good, and not 'neatly' letting me do things that make could do. I worked around them, once I understood SCons better
For example, SCons lets you generate static and shareable objects using 'StaticObject' and 'SharedObject', and will 'do what's necessary' to make that work on your platform. Eg, under *nix, it will add '-fpic' to SharedObject. It will also refuse to let you add a StaticObject into a SharedLibrary. Which in most cases is just what you'd want to stop happening, but... if you KNOW that in a particular case it will work, then SCons is getting in the way. Eg, we wanted a
But... there's workarounds and they all 'make sense', but require a little more SCons knowledge. The mailing list is quite active and helpful, though.
If your project is straightforward (even if it's HUGE), then there's no problems at all.