What the heck would prevent the manufacturer granting their patients the license, then? Copyright is not some law that binds the manufacturers' hands. It gives them the sole disposition of certain aspects of their intellectual property. They are free to grant access to it as they please.
Trade secrets are such until someone independently figures them out. It would be 100% legal for anyone to reverse-engineer the formula for Pepsi or Coca-Cola and publish it. In spite of it being a trade secret.
Every written creative output is copyrighted, unless it's in public domain, so that's a moot point. Whether the licensing terms allow free access is an entirely different issue. Please don't conflate them.
I've shorted the heck out of it and I can't say I'm unhappy. You can play it both hands. I'll finish the buying and close the short once I reach my targets, but it's on a very good track so far.
White balance is done in post-processing anyway, there's nothing physically in a camera (apart from bits of the firmware in some FLASH cells somewhere) that has anything to do with it. Exposure control is done in firmware as well, by taking short, high-noise samples from the image sensor to figure out how much light is coming in. On Mars that's not a big deal as you don't really have any fast changes -- there are no clouds. When a dust storm comes in, it's a gradual change and can be accommodated just by taking high-resolution, longer-exposure pictures and noticing a trend in brightness.
I would tend to agree about the color filters, although I'd also like to how how do the transmission spectra of the filters used on modern CMOS camera imagers for terrerstrial use look? And how do they compare in Q or 50% bandwidth with whatever's on Curiosity's filter wheel(s)?
Dude, I presume it's engineers you're talking about. We're born to look for how to do things better:) Sure, it can be done in a more proper tone, but that's what engineering is all about -- it's all "hey, I bet this can be done better". That's at least how an engineer would start. In the end it may, and usually will, turn out that perhaps it can be done better but it costs too much or would take too long etc. But as a first thing to roll of an engineer's tongue, I'd consider it well within expectations;)
On the contrary, I think that if one presumes that entry-level programming ability should become integral part of the literacy curriculum for the 21st century, then doing such computer-based experiments will be easier than learning the calculus needed to figure things out otherwise.
If all applications were about placing buttons together, you'd be right. But then people ask "ah, well, how hard it may be to have translucent windows/non-rectangular windows". And then they say "well, now I'd like this one widget to be translucent, see". And boom. The painter-based model falls apart. Even if nothing is translucent, using hardware-accelerated rendering is only effective when using a non-painter rendering model.
Without knowing quite a bit of the underlying theory you can actually run the experiment and see for yourself. Early in the college I needed some cut-off values (say in chi-squared test, I don't exactly recall) for which no formula was given and the table in the book was truncated short of values that I needed. I read up on the meaning of those numbers and obtained the needed ones experimentally by throwing lots of coins, so to speak, and validated my method with the numbers already provided in the book. That's just one example where it helped me out. Applied computational statistics is always relevant in the sense that you can use it to arrive at the results that otherwise might take quite a bit of derivation to get closed-form solutions on. Of course one might argue that if you've got a good symbolic math package, all those derivations will be trivial, but still you need to know what equations to start from, and even that might be a bit of work if you're not in the field of statistics.
Huh, a class that handles user events and draws to a rectangular regular is too slow?
Yes. Because when the graphics card does the actual rendering using the modern 3D hardware, you don't need the rectangular window anymore, nor its memory and bandwidth baggage. If you actually understood how it works, and what it takes to composite legacy rectangular widgets, you'd have understood it. As it is, you're talking out of your ass, demonstrably without any technical understanding of what's involved. Sorry.
There are areas to improve painting but that's a reason to fix QPainter.
It's got nothing to do with fixing QPainter, you're delusional if you think so. The model where something changes on the display and user code is asked to do repaints is crazy when you have a piece of very fast graphics hardware that will do all that for you without a single line of code running on the CPU, without a single task switch even though there may be windows from a dozen applications all being updated.
They could have made widgets hardware accelerated and easily animated.
Yes. And that's how QML came to be, because when you actually try to make "widgets" do all that you end up with something that's not widgets anymore. Do you seriously believe that the mindset was "let's come up with something new from scratch, we've got too little work to do"? The legacy widget model has insurmountable performance issues that cannot be overcome in that model. If you don't understand that, you need to do some research first, perhaps actually try coding something up and convincing everyone how your supercool painter widget based model keeps up with competition.
There's no way to get good performance from a painter-based architecture that asks everyone to repaint their part when something changes. This model made sense for a while because common graphics hardware was generally slow and had no acceleration to speak of when it comes to graph-based representations of the visuals. It doesn't make any sense anymore. When a window moves and is to be recomposited, you shouldn't have to transfer more than a command or two to the graphics card to change a couple coordinates. It'll be picked up next time the rendering is done. In the painter-based model, at best you have backbuffers for every window (even if a window has a flat background that can be represented by two flat shaded triangles -- two dozen numbers at the most, not a megabyte), and those backbuffers have to be composited.
The widget model not only sucks performance-wise, but it also sucks resource wise: you need a lot more memory and a lot more memory bandwidth to render even fairly simple things.
I can't imagine a large (1000MW+) generating plant of any sort not having about 0.2%-1.0% of that as backup generating capacity that could be started without any external input. That's like plant design 101. Anyone with current experience please chime in, mine is 2nd hand knowledge. A 10MW backup turbine using liquid fuel that needs a small diesel for startup is not that big of a deal. Sure it costs money when you build the plant, but starting up a big coal plant takes a lot of energy last I heard. A natural gas plant of at least 100MW generating capacity probably could do with 0.1% backup supply if it was designed for it, but it seems like really cutting things down to a minimum (site lights turned off, no CCTV, etc).
You could equate "configurable" with "written in a language higher level than C or C++". I'm sure even Prolog would be better than plain C++ for that, in terms of programmer productivity in writing new rules, testability, verifiability against requirements, and maintainability.
You'd hope they have some sort of a domain specific language inside of their system that can be used to express those rules, validate their consistency, solve constraints (for financial problems, such as how to maximize return on a given investment within certain limits), etc. These days you could use C++ template metaprogramming for that, but there's a point where "leveraging" the C++ compiler turns into digging a hole under yourself. I'd personally not use C++ and simply write the rule language and "engine" from scratch. It could be prototyped in LISP.
What's even better these days, and what makes various excuses not to learn statistics less valid, is the broad availability of raw computing power and free software that lets you easily model things. It used to be that statistics demanded calculus background to arrive at any usable numerical results. These days you can run a fairly complex statistical (random sampling) experiments as numerical simulations. If you don't know a closed-form formula, nor would understand one, you can still obtain experimental results and reason from that. You may not know what the distribution of coin tosses is in a particular case, but you can simply do the tosses, billions of them, and see for yourself. That's why I think that it's inexcusable not to consider basic programming skills as part of being literate these days. Computers are powerful tools that let you perform numerical experiments that can be used to help with everyday reasoning.
Mainly that there's plenty of seemingly simple arguments that literally took centuries to work out and argue. If you question everything, you'll be dead and still stuck a couple centuries ago as far as human thought went. One can't be an expert in everything.
Nature cannot be fooled. Smile -- just because someone lives in their own world of "leadership" make-believe doesn't mean that things will go their way just because they wish it so very, very much.
Precisely. The overwhelming credit card debt and the mortgage fiascos the world over is mainly because people can't figure out simple compound interest.
Math is, to me, a core requirement for civics -- you know, being someone who can't be easily lied to by politicians who pull numbers out of their sleeves and pretend that everything can be solved with their fave solution du jour.
It's easy, really. SCADA typically runs on some embedded platform, other than Unix, that doesn't come with a built-in firewall, and isn't really kept up-to-date to plug security holes. Sure you could run a traffic light controller on Linux, set up with vnc, firewall and selinux, only letting authenticated VNC traffic through. Alas, there seems to be no one out there who provides a full-featured PLC stack on top of Linux. Most everything runs on Windows XP, CE or Embedded, or some industrial RTOS that's probably swiss cheese in terms of vulnerabilities.
Their API is much cleaner than the BSD/Linux accretion disc. Size is only a collateral benefit. You're very much right about the IC pricing being tied to packaging at the low end. I'd still gladly use Contiki no matter how much memory is there.
In the high school where I went to, there was no bragging about "high levels" because every freaking body took them. You came to school on the first day of the semester, and your class schedule (same as mostly everyone else's in your group) was posted on the wall next to the principal's office. If you didn't like it there, you could always go to a lesser school. Same pretty much with the undergraduate curriculum at the university, except that the schedules were on the wall next to the dean's office, there being no position called a principal in the physics department, as it was. And it snowed uphill both ways, too:)
Slashdot Mirror
What the heck would prevent the manufacturer granting their patients the license, then? Copyright is not some law that binds the manufacturers' hands. It gives them the sole disposition of certain aspects of their intellectual property. They are free to grant access to it as they please.
Trade secrets are such until someone independently figures them out. It would be 100% legal for anyone to reverse-engineer the formula for Pepsi or Coca-Cola and publish it. In spite of it being a trade secret.
Every written creative output is copyrighted, unless it's in public domain, so that's a moot point. Whether the licensing terms allow free access is an entirely different issue. Please don't conflate them.
Now be careful, because those 40 y.o. "ladies" are those 20-somethings, 20 years later. You're probably projecting some insecurities of your own.
I've shorted the heck out of it and I can't say I'm unhappy. You can play it both hands. I'll finish the buying and close the short once I reach my targets, but it's on a very good track so far.
White balance is done in post-processing anyway, there's nothing physically in a camera (apart from bits of the firmware in some FLASH cells somewhere) that has anything to do with it. Exposure control is done in firmware as well, by taking short, high-noise samples from the image sensor to figure out how much light is coming in. On Mars that's not a big deal as you don't really have any fast changes -- there are no clouds. When a dust storm comes in, it's a gradual change and can be accommodated just by taking high-resolution, longer-exposure pictures and noticing a trend in brightness.
I would tend to agree about the color filters, although I'd also like to how how do the transmission spectra of the filters used on modern CMOS camera imagers for terrerstrial use look? And how do they compare in Q or 50% bandwidth with whatever's on Curiosity's filter wheel(s)?
Dude, I presume it's engineers you're talking about. We're born to look for how to do things better :) Sure, it can be done in a more proper tone, but that's what engineering is all about -- it's all "hey, I bet this can be done better". That's at least how an engineer would start. In the end it may, and usually will, turn out that perhaps it can be done better but it costs too much or would take too long etc. But as a first thing to roll of an engineer's tongue, I'd consider it well within expectations ;)
On the contrary, I think that if one presumes that entry-level programming ability should become integral part of the literacy curriculum for the 21st century, then doing such computer-based experiments will be easier than learning the calculus needed to figure things out otherwise.
If all applications were about placing buttons together, you'd be right. But then people ask "ah, well, how hard it may be to have translucent windows/non-rectangular windows". And then they say "well, now I'd like this one widget to be translucent, see". And boom. The painter-based model falls apart. Even if nothing is translucent, using hardware-accelerated rendering is only effective when using a non-painter rendering model.
Without knowing quite a bit of the underlying theory you can actually run the experiment and see for yourself. Early in the college I needed some cut-off values (say in chi-squared test, I don't exactly recall) for which no formula was given and the table in the book was truncated short of values that I needed. I read up on the meaning of those numbers and obtained the needed ones experimentally by throwing lots of coins, so to speak, and validated my method with the numbers already provided in the book. That's just one example where it helped me out. Applied computational statistics is always relevant in the sense that you can use it to arrive at the results that otherwise might take quite a bit of derivation to get closed-form solutions on. Of course one might argue that if you've got a good symbolic math package, all those derivations will be trivial, but still you need to know what equations to start from, and even that might be a bit of work if you're not in the field of statistics.
Huh, a class that handles user events and draws to a rectangular regular is too slow?
Yes. Because when the graphics card does the actual rendering using the modern 3D hardware, you don't need the rectangular window anymore, nor its memory and bandwidth baggage. If you actually understood how it works, and what it takes to composite legacy rectangular widgets, you'd have understood it. As it is, you're talking out of your ass, demonstrably without any technical understanding of what's involved. Sorry.
There are areas to improve painting but that's a reason to fix QPainter.
It's got nothing to do with fixing QPainter, you're delusional if you think so. The model where something changes on the display and user code is asked to do repaints is crazy when you have a piece of very fast graphics hardware that will do all that for you without a single line of code running on the CPU, without a single task switch even though there may be windows from a dozen applications all being updated.
They could have made widgets hardware accelerated and easily animated.
Yes. And that's how QML came to be, because when you actually try to make "widgets" do all that you end up with something that's not widgets anymore. Do you seriously believe that the mindset was "let's come up with something new from scratch, we've got too little work to do"? The legacy widget model has insurmountable performance issues that cannot be overcome in that model. If you don't understand that, you need to do some research first, perhaps actually try coding something up and convincing everyone how your supercool painter widget based model keeps up with competition.
There's no way to get good performance from a painter-based architecture that asks everyone to repaint their part when something changes. This model made sense for a while because common graphics hardware was generally slow and had no acceleration to speak of when it comes to graph-based representations of the visuals. It doesn't make any sense anymore. When a window moves and is to be recomposited, you shouldn't have to transfer more than a command or two to the graphics card to change a couple coordinates. It'll be picked up next time the rendering is done. In the painter-based model, at best you have backbuffers for every window (even if a window has a flat background that can be represented by two flat shaded triangles -- two dozen numbers at the most, not a megabyte), and those backbuffers have to be composited.
The widget model not only sucks performance-wise, but it also sucks resource wise: you need a lot more memory and a lot more memory bandwidth to render even fairly simple things.
I can't imagine a large (1000MW+) generating plant of any sort not having about 0.2%-1.0% of that as backup generating capacity that could be started without any external input. That's like plant design 101. Anyone with current experience please chime in, mine is 2nd hand knowledge. A 10MW backup turbine using liquid fuel that needs a small diesel for startup is not that big of a deal. Sure it costs money when you build the plant, but starting up a big coal plant takes a lot of energy last I heard. A natural gas plant of at least 100MW generating capacity probably could do with 0.1% backup supply if it was designed for it, but it seems like really cutting things down to a minimum (site lights turned off, no CCTV, etc).
You could equate "configurable" with "written in a language higher level than C or C++". I'm sure even Prolog would be better than plain C++ for that, in terms of programmer productivity in writing new rules, testability, verifiability against requirements, and maintainability.
You'd hope they have some sort of a domain specific language inside of their system that can be used to express those rules, validate their consistency, solve constraints (for financial problems, such as how to maximize return on a given investment within certain limits), etc. These days you could use C++ template metaprogramming for that, but there's a point where "leveraging" the C++ compiler turns into digging a hole under yourself. I'd personally not use C++ and simply write the rule language and "engine" from scratch. It could be prototyped in LISP.
What's even better these days, and what makes various excuses not to learn statistics less valid, is the broad availability of raw computing power and free software that lets you easily model things. It used to be that statistics demanded calculus background to arrive at any usable numerical results. These days you can run a fairly complex statistical (random sampling) experiments as numerical simulations. If you don't know a closed-form formula, nor would understand one, you can still obtain experimental results and reason from that. You may not know what the distribution of coin tosses is in a particular case, but you can simply do the tosses, billions of them, and see for yourself. That's why I think that it's inexcusable not to consider basic programming skills as part of being literate these days. Computers are powerful tools that let you perform numerical experiments that can be used to help with everyday reasoning.
What's wrong with questioning every argument?
Mainly that there's plenty of seemingly simple arguments that literally took centuries to work out and argue. If you question everything, you'll be dead and still stuck a couple centuries ago as far as human thought went. One can't be an expert in everything.
Although these people are hamperred by lack of a "laboratory" in which to conduct experiments and control variables, they have tools such as [...]
You meant to say they are stuck in times of Aristotle. All thought experiments. Thank you for saying it like it is.
Nature cannot be fooled. Smile -- just because someone lives in their own world of "leadership" make-believe doesn't mean that things will go their way just because they wish it so very, very much.
Precisely. The overwhelming credit card debt and the mortgage fiascos the world over is mainly because people can't figure out simple compound interest.
Math is, to me, a core requirement for civics -- you know, being someone who can't be easily lied to by politicians who pull numbers out of their sleeves and pretend that everything can be solved with their fave solution du jour.
It's easy, really. SCADA typically runs on some embedded platform, other than Unix, that doesn't come with a built-in firewall, and isn't really kept up-to-date to plug security holes. Sure you could run a traffic light controller on Linux, set up with vnc, firewall and selinux, only letting authenticated VNC traffic through. Alas, there seems to be no one out there who provides a full-featured PLC stack on top of Linux. Most everything runs on Windows XP, CE or Embedded, or some industrial RTOS that's probably swiss cheese in terms of vulnerabilities.
Their API is much cleaner than the BSD/Linux accretion disc. Size is only a collateral benefit. You're very much right about the IC pricing being tied to packaging at the low end. I'd still gladly use Contiki no matter how much memory is there.
And those are *optical* amplifiers, no less.
In the high school where I went to, there was no bragging about "high levels" because every freaking body took them. You came to school on the first day of the semester, and your class schedule (same as mostly everyone else's in your group) was posted on the wall next to the principal's office. If you didn't like it there, you could always go to a lesser school. Same pretty much with the undergraduate curriculum at the university, except that the schedules were on the wall next to the dean's office, there being no position called a principal in the physics department, as it was. And it snowed uphill both ways, too :)