Uh, no... It's not forcing anything except making the stores be legally unable to sell the stuff instead of by their own decision.
It's no different than it is now, except that now you've got a law to selectively enforce on the books- just like every other law there is. Hell, they're selectively enforcing much more important laws right now with immigration right at the moment.
Polls are so inaccurate in most cases. Most people don't get that unless you have a HUGE sample set that represents properly the population you're claiming you're sampling- you don't even have a whiff of the real picture.
Much like statistics, there's lies, damned lies, and polls.
It probably ought to be classified under the existing obscenity laws- we don't really need more legislation, we need LESS. More to the point, you should be able to classify it under those existing laws without any ability to challenge the same- and the penalties there are good enough to keep people from doing it.
That's slowly changing (thank the Lord...seriously...)- many of the towns and counties are wising up to the reality that the "dry" position was being silly and it was actually contributing to the problem they were trying to prevent. The nearest Liquor stores in the Flower Mound and Lewisville areas was in Highland Village and in Lake Dallas, just all of about 10-15 minutes' drive to the North of those respective towns. All that they were accomplishing was encouraging drinking and driving and they were doing themselves out of sales, etc. Now, it was entertaining to watch the fundies (which work off of feelings instead of thoughts...) whip themselves into a froth over the move to wet in those towns- never mind that the Holy Bible clearly indicates that drink is proper and good if taken in moderation.
Brilliant question... Why do you need a law? You don't need the government to play nanny for your kids- you, as a parent, should be responsible for their upbringing and making bans won't do a single thing to keep the ones that're going to get it from getting access to violent games.
Much like minors getting ahold of alcohol or cigarettes. Yes, we need to largely prevent their access to those things- but without parental guidance and oversight, they'll still get the stuff anyhow.
If you have 110-220v capable caps, it'd meet the criteria we're discussing- all you need to do to mitigate the flicker we're discussing is add a bit of extra persistence to the system design.
Systems producing 800-1000lm of output tend to be HUGE arrays of low-power devices (and I do MEAN huge...) or smaller arrays of fairly high power chips which need to rid themselves of the heat to survive long periods of time.
You're talking about 7-15 watts roughly here for the more advanced parts in this class right at the moment. Passive MIGHT work on the low end for things as long as you allow for proper convective dissipation of that (heat rising, light as a downlight- and you allow the heat to leave the fixture...)- but at the high end, you're going to need a huge passive sink or active convection cooling.
You're not going to find one. Not right at the moment unless you roll your own.
1) You need a constant current regulator for the LEDs which at these levels will need at least a HUGE passive sink for the parts. If you don't get a constant current regulator and supply, the LEDs will prematurely burn themselves out.
2) The LED's that produce 800-1000 lumen outputs tend to be a HUGE array of tiny LED chips so they don't produce much heat- or a huge honking high power chip or five that dissipate a bit of heat, still needing some sort of heat sink to get rid of about 9-15 watts of heat from the chips.
The main drawback to incandescents is that they're rather inefficient light sources and fairly efficient heaters. Now, had the DOE research into major advancements in materials science for them (and thereby placing their efficiencies in the realm of the theoreticals for LEDs...) had panned out in time and proved to be economical- I'd be all for keeping them.
Your issues- I can concur with the dim turn ons (while not all bulbs have this issue, the bulk of them do- and the ones that don't aren't cheap either...) and premature heat death (I find that the ones that suffer this problem are the el-cheapo ones everyone seems to be plugging these days...)- but the problems of the increased thermal load within a house during summer months and the increased consumption of electricity, resulting in increased emissions from coal fired plants (They may be "clean" but they're producing pollutants similar in toxicity and quantity to the bulbs you rail at- just diffused better than a point source mishap from a bulb breaking here and there...) make for a hard sell for your position. It's almost six of one, half dozen of another with it.
I'm not sure what the answer is- but if CFLs aren't a short-term answer, neither is holding on to incandesants when they have their own issues to begin with. I'd say that, probably, LED/OLED technology is probably the answer there- or perhaps improved EL tech (though with all the years they've had with it, I doubt they'll get anywhere with it in comparison to LEDs...). The main stumbling block is the expense of the "bulbs"- which comes from them being so "new" and only recently really able to get a whiff of real lighting ability similar in nature to incandesants and mercury vapor fluoresents. I'd just wish the early bulb manufacturers in the LED space would have told more honest statements about their overall performance.
Heh... Perhaps- but can you GET that sort of service from Comcast without establishing a business account (and thereby those prices...)?
Probably not.
The truth of the matter is this: You are getting a fractional T3's worth of bandwidth with the corresponding latencies for 1/6-1/10th the cost. It's comparable to what I'm spending with Verizon for a similar level of service on a business account.
This presumes you can get the proper plaintext determined that way.
With a one-time pad, you're talking about something where you can conceivably get "intelligible" content and it could be the message with chaff around it- or it could be a false positive. Unless you know the plaintext from before it was encoded (along with any chaff measures you might have applied to the selfsame...)- you can't be sure you've got the message.
The only remaining driver would be the SGX drivers for the GPU on the SoC. Can't get away from that one. You're still facing...heh...interesting issues there and I'd love to see them reconcile their stance in light of there being really NO credible mobile solution GPUs that're Open Source friendly- they're all closed source blobs from start to finish except for the command dispatch end that sits in kernel space.
1) Uh... Don't you document your device's interfaces so you can code to them? If not...heh...remind me not to buy your company's tech... >;-D
2) Puffery is puffery. And worrying about this is in the same vein as the security argument. If you can have a bad situation because of flaws in the framework, what else is broken. I'd not use your product. Keep in mind, though, with me you're likely to be talking 10k+ units worth of revenue if I'm the guy you're talking to. If you're doing this, you may well be a no-buy item for a project I'm trying to bring about.
3) End users won't if AMD's situation is any indicator. Ditto Intel's.
4) Heh... I'm sure they'd change their tune if someone as big as Dell, HP, or IBM leaned on them a bit to change that tune of theirs.
5) I hardly think that any company (Broadcom, even) could sustain a 10-100k unit lost sale these days. Unless you're a niche player somewhere, you can end up experiencing something like it from one of the OEM players in the future.
1) Great reason (Probably the ONLY really good one, business reasons-wise, you've given- but even it has answers to it...). However, that's the driver functionality you're doing that with (and it leads to "why?" as a question to be asked next- much of the selfsame functionality is there in the Linux kernel without you needing to license anything; you can always build an abstraction layer that smooths away the needs with Windows and MacOS for proprietary license stuff in the driver layer.
2) Really? I've seen this argument ran up a flagpole repeatedly- typically in the form of, "if they had our source code, they could fabricate a worst-case scenerio against our flaws in the silicon and make us look bad". Calling that "competitive advantage" is the typical play there- and it's merely being sloppy with the silicon and then hiding your sins in the driver layer. I know, at least two of my contract consulting clients for custom driver work have been in that baliwick.
3) I'd say that you'd have to ask AMD about that one. I think you're going to find that they're not fielding ANYWHERE near the level of that sort of thing as you're implying. They seem to not be regretting what they've done with the Radeon info and have kept doing it right on with the latest stuff- along with helping where they saw it useful for their own goals.
4) LAME. Seriously. Hiding security flaws by obscurity is a certain way to get someone to eventually stumble across your failings and misuse them. If you've got a bad design, FIX IT. If you can't fix it, don't be selling it. If you sell it, that'd be an EPIC FAIL on your company's part.
5) I'll point to AMD (and Intel, for that matter) here- they seem to find that there's little to no problems. Same with HP, Epson, and a few others on printers and scanners. In the end, that's a valid argument, but it's a lot weaker than you're making it out to be.
That depends entirely on whether Broadcom was working with any of the distribution vendors while working on releasing it. If so, you might just see at least a "probably works" driver offered for 10.10. (As an aside, I find it interesting that 10.10 actually reported the mouse support for VirtualBox as it is... What else have they got in store for us this rev?)
Explain how an antivirus program with up-to-date definitions would help against a "0-day" exploit? By definition, that means it's so damn new the antivirus/antimalware bunch don't have signatures, etc. to defend against attacks using the exploit.
Relying on an antivirus program to protect you is like relying on closing the barn door to keep the horses in their stalls after they've gotten out of the barn.
Oh - and we are not lazy as some have suggested. My team pulled a 32 hour session last week.
32 hour session? Uh, dude... I'm less than impressed. That's not hard work, that's sadomasochism in the workplace, brought on by badly missed deadlines for some un-stated reason. And it tells us quite a bit about WHY the quality isn't as much there as we've expected out of the past Adobe products and releases- and shows a glimpse of why we're not seeing 64-bit anything out of your claimed employer.
Going that long without breaks and sleep leads me to believe you're actually the CAUSE of some of this stuff we're talking to. You WILL make mistakes past that 12 hour wall- it's human nature, pure and simple. Will you catch them? Maybe, maybe not- test isn't there as a safety net for this kind of crap and if they're working as hard as the devs, they'll miss stuff too. I won't really work much past 10 hours for myself as I'm going to start making dumb mistakes in that last two hours before the hard limit for people. If it were me, even as an anon coward, I'd not be bragging about going nearly 3 times past the hard limit for humans for the tasks we're talking about here.
Either that or someone in management pooched things either because they mis-estimated the effort or resources, or took on something like Scrum without first being very aware that it won't speed up development (It might improve quality, but it won't speed up ANYTHING...adding process on top of things almost always slows down things...).
As you point out, it typifies bad management to have that sort of thing or having people work weekends, etc. You need breaks from things to stay reasonably fresh- without them you start making more mistakes, which then need to be compensated for with more crunch time, etc.
A ton of hours weighs heavily on the soul- perhaps worse than the ton of dollars would be on your body. But, if they pay you well...you can save up and go elsewhere when you burn out on the ton of hours...
If they don't pay you well, though...heh...best look for work elsewhere when you can.
Uh...check your math there... A 40 hour work week comprises of an average of 5 8-hour sessions. You just described a 60 hour work week there. I'd rather not do that sort of thing. I'd rather be working the latter than the former (12 hour days doing programming tend to make for issues- at some point you break as much or more than you fix doing it.), or if you're needing to jam a bit more into something by a calendar date, I'd rather did 10 hour days (50 with 5, the 60 with saner hours over 6 days with at least one day off.).
And it should be observed that Evince is also available for Windows and is under the GPLv2.
Sumatra's minimalistic and lacks some functionality, if you want the honest appraisal- the dev site openly admits not everything renders correctly. Evince seems to be pretty solid when it comes to rendering content correctly. I've yet to find a document that didn't view and print as the author of the document had intended.
What's braindead is that many employers are going "paperless" with them- and you HAVE to view the stubs online.
Re:If they can do it to Google, they can do it to
on
The Case For Oracle
·
· Score: 1
Ah...but Dalvik isn't a JVM, it's a DVM (Dalvik Virtual Machine)- and Oracle isn't suing Google over Java, but rather over VM's in general.
And the prior art in that space is going to be brutal as the bulk of the concepts existed MANY years before Java was even conceived with things like UCSD's P-Code system.
Slashdot Mirror
Uh, no... It's not forcing anything except making the stores be legally unable to sell the stuff instead of by their own decision.
It's no different than it is now, except that now you've got a law to selectively enforce on the books- just like every other law there is. Hell, they're selectively enforcing much more important laws right now with immigration right at the moment.
Polls are so inaccurate in most cases. Most people don't get that unless you have a HUGE sample set that represents properly the population you're claiming you're sampling- you don't even have a whiff of the real picture.
Much like statistics, there's lies, damned lies, and polls.
It probably ought to be classified under the existing obscenity laws- we don't really need more legislation, we need LESS . More to the point, you should be able to classify it under those existing laws without any ability to challenge the same- and the penalties there are good enough to keep people from doing it.
That's slowly changing (thank the Lord...seriously...)- many of the towns and counties are wising up to the reality that the "dry" position was being silly and it was actually contributing to the problem they were trying to prevent. The nearest Liquor stores in the Flower Mound and Lewisville areas was in Highland Village and in Lake Dallas, just all of about 10-15 minutes' drive to the North of those respective towns. All that they were accomplishing was encouraging drinking and driving and they were doing themselves out of sales, etc. Now, it was entertaining to watch the fundies (which work off of feelings instead of thoughts...) whip themselves into a froth over the move to wet in those towns- never mind that the Holy Bible clearly indicates that drink is proper and good if taken in moderation.
Brilliant question... Why do you need a law? You don't need the government to play nanny for your kids- you, as a parent, should be responsible for their upbringing and making bans won't do a single thing to keep the ones that're going to get it from getting access to violent games.
Much like minors getting ahold of alcohol or cigarettes. Yes, we need to largely prevent their access to those things- but without parental guidance and oversight, they'll still get the stuff anyhow.
Define power supply circuit.
If you have 110-220v capable caps, it'd meet the criteria we're discussing- all you need to do to mitigate the flicker we're discussing is add a bit of extra persistence to the system design.
Sorry, but this is at least partially wrong.
Systems producing 800-1000lm of output tend to be HUGE arrays of low-power devices (and I do MEAN huge...) or smaller arrays of fairly high power chips which need to rid themselves of the heat to survive long periods of time.
You're talking about 7-15 watts roughly here for the more advanced parts in this class right at the moment. Passive MIGHT work on the low end for things as long as you allow for proper convective dissipation of that (heat rising, light as a downlight- and you allow the heat to leave the fixture...)- but at the high end, you're going to need a huge passive sink or active convection cooling.
You're not going to find one. Not right at the moment unless you roll your own.
1) You need a constant current regulator for the LEDs which at these levels will need at least a HUGE passive sink for the parts. If you don't get a constant current regulator and supply, the LEDs will prematurely burn themselves out.
2) The LED's that produce 800-1000 lumen outputs tend to be a HUGE array of tiny LED chips so they don't produce much heat- or a huge honking high power chip or five that dissipate a bit of heat, still needing some sort of heat sink to get rid of about 9-15 watts of heat from the chips.
The main drawback to incandescents is that they're rather inefficient light sources and fairly efficient heaters. Now, had the DOE research into major advancements in materials science for them (and thereby placing their efficiencies in the realm of the theoreticals for LEDs...) had panned out in time and proved to be economical- I'd be all for keeping them.
Your issues- I can concur with the dim turn ons (while not all bulbs have this issue, the bulk of them do- and the ones that don't aren't cheap either...) and premature heat death (I find that the ones that suffer this problem are the el-cheapo ones everyone seems to be plugging these days...)- but the problems of the increased thermal load within a house during summer months and the increased consumption of electricity, resulting in increased emissions from coal fired plants (They may be "clean" but they're producing pollutants similar in toxicity and quantity to the bulbs you rail at- just diffused better than a point source mishap from a bulb breaking here and there...) make for a hard sell for your position. It's almost six of one, half dozen of another with it.
I'm not sure what the answer is- but if CFLs aren't a short-term answer, neither is holding on to incandesants when they have their own issues to begin with. I'd say that, probably, LED/OLED technology is probably the answer there- or perhaps improved EL tech (though with all the years they've had with it, I doubt they'll get anywhere with it in comparison to LEDs...). The main stumbling block is the expense of the "bulbs"- which comes from them being so "new" and only recently really able to get a whiff of real lighting ability similar in nature to incandesants and mercury vapor fluoresents. I'd just wish the early bulb manufacturers in the LED space would have told more honest statements about their overall performance.
Heh... Perhaps- but can you GET that sort of service from Comcast without establishing a business account (and thereby those prices...)?
Probably not.
The truth of the matter is this: You are getting a fractional T3's worth of bandwidth with the corresponding latencies for 1/6-1/10th the cost. It's comparable to what I'm spending with Verizon for a similar level of service on a business account.
This presumes you can get the proper plaintext determined that way.
With a one-time pad, you're talking about something where you can conceivably get "intelligible" content and it could be the message with chaff around it- or it could be a false positive. Unless you know the plaintext from before it was encoded (along with any chaff measures you might have applied to the selfsame...)- you can't be sure you've got the message.
The only remaining driver would be the SGX drivers for the GPU on the SoC. Can't get away from that one. You're still facing...heh...interesting issues there and I'd love to see them reconcile their stance in light of there being really NO credible mobile solution GPUs that're Open Source friendly- they're all closed source blobs from start to finish except for the command dispatch end that sits in kernel space.
1) Uh... Don't you document your device's interfaces so you can code to them? If not...heh...remind me not to buy your company's tech... >;-D
2) Puffery is puffery. And worrying about this is in the same vein as the security argument. If you can have a bad situation because of flaws in the framework, what else is broken. I'd not use your product. Keep in mind, though, with me you're likely to be talking 10k+ units worth of revenue if I'm the guy you're talking to. If you're doing this, you may well be a no-buy item for a project I'm trying to bring about.
3) End users won't if AMD's situation is any indicator. Ditto Intel's.
4) Heh... I'm sure they'd change their tune if someone as big as Dell, HP, or IBM leaned on them a bit to change that tune of theirs.
5) I hardly think that any company (Broadcom, even) could sustain a 10-100k unit lost sale these days. Unless you're a niche player somewhere, you can end up experiencing something like it from one of the OEM players in the future.
1) Great reason (Probably the ONLY really good one, business reasons-wise, you've given- but even it has answers to it...). However, that's the driver functionality you're doing that with (and it leads to "why?" as a question to be asked next- much of the selfsame functionality is there in the Linux kernel without you needing to license anything; you can always build an abstraction layer that smooths away the needs with Windows and MacOS for proprietary license stuff in the driver layer.
2) Really? I've seen this argument ran up a flagpole repeatedly- typically in the form of, "if they had our source code, they could fabricate a worst-case scenerio against our flaws in the silicon and make us look bad". Calling that "competitive advantage" is the typical play there- and it's merely being sloppy with the silicon and then hiding your sins in the driver layer. I know, at least two of my contract consulting clients for custom driver work have been in that baliwick.
3) I'd say that you'd have to ask AMD about that one. I think you're going to find that they're not fielding ANYWHERE near the level of that sort of thing as you're implying. They seem to not be regretting what they've done with the Radeon info and have kept doing it right on with the latest stuff- along with helping where they saw it useful for their own goals.
4) LAME. Seriously. Hiding security flaws by obscurity is a certain way to get someone to eventually stumble across your failings and misuse them. If you've got a bad design, FIX IT. If you can't fix it, don't be selling it. If you sell it, that'd be an EPIC FAIL on your company's part.
5) I'll point to AMD (and Intel, for that matter) here- they seem to find that there's little to no problems. Same with HP, Epson, and a few others on printers and scanners. In the end, that's a valid argument, but it's a lot weaker than you're making it out to be.
That depends entirely on whether Broadcom was working with any of the distribution vendors while working on releasing it. If so, you might just see at least a "probably works" driver offered for 10.10. (As an aside, I find it interesting that 10.10 actually reported the mouse support for VirtualBox as it is... What else have they got in store for us this rev?)
Uh, that's as much a BAD idea as the one you're deriding there.
Updates CAN break machines or accidentally inject possibilities for other exploits.
You want to KNOW what in the heck you're updating and why before doing it. Seriously.
Explain how an antivirus program with up-to-date definitions would help against a "0-day" exploit? By definition, that means it's so damn new the antivirus/antimalware bunch don't have signatures, etc. to defend against attacks using the exploit.
Relying on an antivirus program to protect you is like relying on closing the barn door to keep the horses in their stalls after they've gotten out of the barn.
32 hour session? Uh, dude... I'm less than impressed. That's not hard work, that's sadomasochism in the workplace, brought on by badly missed deadlines for some un-stated reason. And it tells us quite a bit about WHY the quality isn't as much there as we've expected out of the past Adobe products and releases- and shows a glimpse of why we're not seeing 64-bit anything out of your claimed employer.
Going that long without breaks and sleep leads me to believe you're actually the CAUSE of some of this stuff we're talking to. You WILL make mistakes past that 12 hour wall- it's human nature, pure and simple. Will you catch them? Maybe, maybe not- test isn't there as a safety net for this kind of crap and if they're working as hard as the devs, they'll miss stuff too. I won't really work much past 10 hours for myself as I'm going to start making dumb mistakes in that last two hours before the hard limit for people. If it were me, even as an anon coward, I'd not be bragging about going nearly 3 times past the hard limit for humans for the tasks we're talking about here.
Either that or someone in management pooched things either because they mis-estimated the effort or resources, or took on something like Scrum without first being very aware that it won't speed up development (It might improve quality, but it won't speed up ANYTHING...adding process on top of things almost always slows down things...).
As you point out, it typifies bad management to have that sort of thing or having people work weekends, etc. You need breaks from things to stay reasonably fresh- without them you start making more mistakes, which then need to be compensated for with more crunch time, etc.
2000# for the ton of dollars.
A ton of hours weighs heavily on the soul- perhaps worse than the ton of dollars would be on your body. But, if they pay you well...you can save up and go elsewhere when you burn out on the ton of hours...
If they don't pay you well, though...heh...best look for work elsewhere when you can.
Uh...check your math there... A 40 hour work week comprises of an average of 5 8-hour sessions. You just described a 60 hour work week there. I'd rather not do that sort of thing. I'd rather be working the latter than the former (12 hour days doing programming tend to make for issues- at some point you break as much or more than you fix doing it.), or if you're needing to jam a bit more into something by a calendar date, I'd rather did 10 hour days (50 with 5, the 60 with saner hours over 6 days with at least one day off.).
And it should be observed that Evince is also available for Windows and is under the GPLv2.
Sumatra's minimalistic and lacks some functionality, if you want the honest appraisal- the dev site openly admits not everything renders correctly. Evince seems to be pretty solid when it comes to rendering content correctly. I've yet to find a document that didn't view and print as the author of the document had intended.
What's braindead is that many employers are going "paperless" with them- and you HAVE to view the stubs online.
Ah...but Dalvik isn't a JVM, it's a DVM ( Dalvik Virtual Machine)- and Oracle isn't suing Google over Java, but rather over VM's in general.
And the prior art in that space is going to be brutal as the bulk of the concepts existed MANY years before Java was even conceived with things like UCSD's P-Code system.
Then the systems really weren't air-gapped, you had a sneakernet between them.
Air-gapped means that never the two shall ever meet. Nothing like a flash or CD/DVD to be shared between the trusted and untrusted network can happen.