Verifying temperatures isn't generally that easy - mainly because what most systems are designed to measure isn't what most humans want to hear from it.
The first law of thermodynamics is we don't talk about thermodynamics.
Many monitoring packages typically fudge their numbers to some extent. It's a case of "A little inaccuracy can save a great deal of explanation."
The (vast majority) of people who even look at CPU temps are enthusiasts who think they know something about die thermals, but really have no fraking clue, other than "hot bad". A hard number is easy to understand - even if it's a lie or doesn't tell you anything that's actually useful.
Die temperatures (as measured by a thermal diode) can vary quite a bit compared to heatsink temperatures. Even then - move the probe to a different point on the heatsink, and the temp measured can vary even more. This means that comparing a thermal diode's temperature (ie. on-die in the GPU) vs. anything you can measure externally (via heatsink) is going to be a lot more trouble than it's worth -- and it's going to be different for every combination of die/heatsink/fan/chassis.
There are usually entirely different goals in temperature measurement. While a fixed temp is easy for a human to understand, a fixed temp isn't that great of a metric for a CPU's (or it's cooling system's) thermal health.
For example, Intel's PECI doesn't report absolute temperatures; it reports a negative value which represents the number of degrees until the core is "hot" - which isn't based on any fixed temperature. Some (wrongly) look at the CPU's max temp spec, and figure they can translate that to an actual temp.
In reality, it's like asking your wife "are you hot?" and then guessing what the temperature is from her reply. The result can vary depending on any of a number of external factors. More importantly, the number doesn't really matter to begin with. What matters is how your wife feels.
The "external factors" for a silicon die would be things like load, the volume, velocity, and temperature of the coolant air over the heatsink, heatsink size/geometry/material, airflow patterns in the chassis... Manufacturers (be they Intel, AMD, NVIDIA, or anybody else) don't have the luxury of controlling any of those variables, so they either have to design adaptive systems, or throw performance out the window in by throttling the core when they don't really have to.
AMD may not have the best drivers, but I dont recall any AMD drivers that allowed me to play games and fry eggs with the same piece of hardware like Nvidia.
You don't seem to have looked hard enough at the AMD drivers, or developed software that uses them.
I write management software for supercomputing clusters - and GPU's are one of the shiny things right now. Mainstream GPU drivers have hooks that let us do things that admins like to know about - monitor temps, fan speeds, voltages, etc.
Unfortunately, AMD's driver's aren't just bad. I'm not a lawyer, but there's a good chance they are criminally bad.
Fatal flaws that I know of: * It's trivial to write a program that will shut off the GPU's cooling fan with the AMD drivers; as well as disabling any overtemp throttling. I'm honestly surprised malware hasn't been written to do this already. Either way, your eggs will be ready shortly. I hope the building doesn't burn down.
* This is a gripe on their Linux drivers, but it's fair game: AMD's own instructions explicitly state that to make GPU monitoring available to a monitoring daemon (or to make GPU crunching available to remote users), it's necessary to run "xhost +" as root.
Whiskey, Tango, Foxtrot
For those that don't know - runining "xhost +" as root isn't as bad as having an empty root password, but it's near the top of the list of batshit-stupid things to do. None of AMD's competitors require opening one of the biggest security holes possible just to use their product. What's worse: AMD's response is that they won't be doing anything about it for the forseeable future.
Other GPU makers aren't without problems - everybody has faults - but it speaks volumes that AMD has no intention of fixing a grave security bug in their drivers.
When you want to design an build a house, you don't start out by designing and building a car to park in the garage.
That's not even an analogy: The car isn't even part of the house. It can be removed or omitted, and doesn't change the properties or functionality of the house at all.
To use your house analogy, a touch screen would be like designing the roof for the house. Rip out the roof, and the house isn't a house anymore.
I don't really understand why you can't understand this: A touchscreen is just another part - just like a resistor, capacitor, switch, inductor, LED, etc. Nearly all electronics work involves connecting components together. Yes, a touch screen has many sub-components - but the same is true of every other electronic part, including something dead-simple like a circuit board or a resistor.
You read the touch screen's data sheet, and implement the interface. There are color touch screens for $30 that have workable interfaces; a 16-bit parallel bus for the graphics, a couple control pins, and four pins for touch sensing. No big deal; you can drive that with a DIP micro controller.
If you actually wanted to make a touch-screen interface for its own sake, you would want it somewhere you could show it off (like your pocket), not hidden in your furnace room.
At what point was showing off the project a design goal? If showing it off is your goal, then you're not doing the design for its own sake, but for the sake of showing off.
I seem to recall the OP's goal being "make an embedded device with a touchscreen." - not write a smartphone or tablet application, and not buy an already-working device.
I'm perfectly happy with a touchscreen design hidden in my furnace room. Having a sprinkler control system with a touch screen is pretty cool, and a lot less intimidating for my wife. There's a tremendous amount of personal satisfaction in knowing that I've made a reliable, user-friendly system.
If I'm doing something for its own sake, I'm more interested in the journey to get there than the end product. The end product is often just an excuse for the journey.
Your argument is like saying somebody shouldn't cook, because there's an abundance of restaurants and prepackaged, prepared food.
Some of us like designing hardware from components. We like designing circuits, laying out printed circuit boards (and fabricating them), component soldering - including things like toaster-oven reflow soldering. We like debugging wire protocols, using logic analyzers, and yes, programming microcontrollers.
Being able to say "yes, I can design products that use a touch screen" can be very helpful in a job interview.
Let's not forget that the patent system doesn't just cover electrical & programming tech.
It also covers chemical, pharma, materials, manufacturing, physical machines, etc.
It's a mess having one patent system to cover everything under the sun.
The problem is that there would be an even bigger mess if there were different rules and multiple categories.
Patents do have a useful purpose, even today. It does provide incentive to do long-term R&D.
The problems I see: 1.) Corporate Arrogance:
- Patent licenses are often far more expensive than they are worth.
- Companies decide it's cheaper to litigate than to license - and as often as not, they are right.
- "A good is worth exactly what its buyer is willing to pay" - when a federal patent lawsuit is the cheaper option for your customers, your good is overpriced. 2.) Parts of the law are written in a way that encourage lawsuits:
- There's no incentive to find out what other companies have patented; in fact, you are penalized for it. I understand the reasons why it's written that way, though. 3.) The patentability bar is too low.
Patents are generally seen as a good thing - they provide incentive for long-term R&D. It's not as apparent in the computer industry, but it is in others.
The problem is writing an effective law is not easy - it's harder than writing code that's completely free of bugs and security holes. The difference is there's tremendous pressure to just leave the bugs in place. "it worked in the past! It can't be wrong!" (i.e. the fallacy that nothing ever changes, and laws can't/shouldn't be changed.)
Or any of the legion of ham radio operators worldwide.
Hams know all too well that their transmitter can easily overpower their neighbor's TV reception.
I know when I did ham radio as a teen, some of the exam questions were about how to deal with neighbors who are angry that you're ruining their reception.
Really? When was the last time you were in a housing project? Did you take ANY time to get to know the poor? Or are you making blanket assumptions based on lame and uninformed propaganda?
Your statement positively oozes contempt for people you quite obviously have no clue about. In my mind, anyone who sneers at a human being because of their poverty is worse than a card-carrying KKK neo-nazi. It's every bit as prejudiced as the belief that a person's color has anything to do with their character.
I spent years working with the poor; I spent more time in the projects than many of the residents. I took the time to get to know them as human beings.
In my experience, their situation has absolutely nothing to do with not wanting to work. I get so sick of hearing ignorant pricks say some lame line like "work at McDonalds." There is no unlimited supply of jobs available anywhere. The poor want jobs - badly. They want to work, and do so when they can.
But you know what? The kinds of hours they have to work isn't sustainable by the human body. The body inevitably breaks down from the strain, and they eventually cannot physically go to work. I've regularly seen people work to the point they pass out, after which they are fired. I know because I paid for college by working at such a job. Naturally, the corporation provides no health care coverage, so there is no treatment or physical therapy to get them back into the work force. Workman's comp? Are you joking? You haven't seen corporate america at work.
I'm convinced those who are constantly whining about 'the lazy poor' understand a lot less about economics than the teenage dropouts they demonize.
I'd be interested in seeing how the Saleae 16 stacks up against the OpenBench Logic sniffer; they both seem to fit into the same niche, and both use the same Xilinx FPGA to measure the signals, so the capabilities have got to be similar I have an OLS, and so far, I'm pretty happy with it.
And along the same note, I wonder how the Beagle compares to the "Bus Pirate." The Bus Pirate supports 1-Wire, I2C, SPI, & JTAG, so at least on the surface it looks pretty good.
I know the OpenBench Logic Sniffer and Bus Pirate are fully "open-source" hardware & software; and are much less expensive - at $50 for the OLS, and $30 or so for the Bus Pirate.
But I have to agree with you - collecting the data is one thing, but sorting through it is what separates a toy from a tool.
The Nano is a digital storage oscilloscope - which is no doubt useful. It shows continuous voltage levels over time, and is great for analog signals; it measures 0-10V at 1Msps, with 12-bits of resolution.
But a logic analyzer fits into a different niche; it really only measures "high" or "low", but across many channels (instead of 1 or 2 as in an oscilliscope).
The OpenBench Logic Sniffer, for example, measures:
- Up to 32 channels at 100 MHz
- Up to 16 channels at 200 MHz
- 1.8-5V, which covers most digital chips.
- costs $50 - almost half of the Nano's price.
They are clearly different tools, though. If I were measuring PPM coming out of a microcontroller (as in an arduino), I'd choose a Logic Analyzer over an oscilliscope.
Re:I'm a fan but they are STILL missing the boat.
on
BlackBerry 10 Unveiled
·
· Score: 1
To regain market share, RIM needs a product that will:
1. Be the BEST and most integrated social networking tool.
2. Be a WALLET by leveraging their existing encryption infrastructure.
No matter what gee-whiz bang they add to the hardware, RIM is still stuck with the features & API that the social networks provide to RIM - and every other platform.
Microsoft tried to go social with a couple of Windows phones - one was summarily canceled on the day of release. Microsoft tried again with Windows Phone 7, and was met with chirping crickets. I doubt RIM or anyone else would do better.
RIM's vaunted existing encryption and infrastructure isn't that special these days; it's certainly nothing that isn't provided by Google or iCloud.
Unfortunately, I think RIM had their one great idea over a decade ago, and have been resting on that ever since. The clock slowly ticked away - it was only a matter of time before RIM's products weren't that special anymore without some serious innovation - and another 'great idea.'
That day has come and gone; RIM ran out of time, and had nothing - literally nothing in the pipeline; their copies of the iPhone and iPad weren't just bad, they were comically bad. Their tablet couldn't even read email - the one thing you'd think RIM could get right.
I did the PC gaming rig thing for two decades. Add that to my computer engineering degree, and my profession making supercomputers. Don't make me laugh about "proper planning." I've dealt with more types and generations of hardware than most people have in their worst nightmares - I know what works, and what doesn't. I've had to clean up other people's messes for ages.
To expand on your list: * No need to worry about upgrading the video card * No need to worry about upgrading RAM * No need to worry about upgrading the Motherboard * No need to worry about upgrading the CPU * No need to worry about upgrading the Disk Drive * No need to worry about upgrading any peripherals * No worrying about the massive money pit called a "gaming rig" * No worrying that you're "missing out" by not constantly upgrading your system * No worry about losing a competitive advantage by not upgrading your system * No worrying about compatibility
I used to be a big PC gamer (for about 20 years, actually), but got tired of the constant expense & fight with the hardware, software, and drivers to keep my system upgraded to the point I could play the games I wanted to. I grew tired of sitting at my gaming PC when I got home from work - in essentialy the same posture & environment as my cubicle.
Consoles remove most of that problem. Wanna play CoD while laying on your side? With a console, it's no problem. With a gaming rig, it's not so easy, if at all. Is a new "must have" game coming out? There's no need to upgrade the system to play it; just pop in the disc and rock.
The bottom line is consoles are far cheaper, I don't have to deal with "spec fanbois" constantly boasting (or moaning) about hardware in their system, and consoles "just work".
There is a lot of confusion here from people who have obviously never configured Airport devices.
Most routers provide a web interface. The configuration interface is part of the router's firmware, and it can be assumed that if the configuration interface doesn't have a setting, it doesn't exist.
This is not the case with Airport devices.
Airport devices do not provide a web interface; the only way to configure them is through the "Airport Configuration Utility" which runs as an application on your PC, Mac, or iOS device. The Airport device's firmware hasn't changed - it still provides the same functionality it always has.
Second, there is a difference between between native IPv6 and running a 6to4 tunnel. One is "real" IPv6, the other is a hack for early adopters who want to gain experience with IPv6, even though their ISP doesn't provide it.
The Airport firmware hasn't removed any IPv6 support at all. As far as I can tell (and I've set it up on my home network), if an Airport device is given native IPv6 addresses & routing, it uses them and passes them along to devices that connect to the Airport network. "It just works."
The catch is that you cannot configure a 6to4 tunnel using Airport Configuration Utility 6. A 6to4 tunnel is the only way to get IPv6 for most of us, so many cry that the sky falling, etc. (Even though Apple released a new version of ACU - 5.6 - the same day as 6.0 - and 5.6 still has 6to4 tunnel configuration)
For those of us geeks that want IPv6, 6to4 is fine; we're using it for exactly the purpose it was designed for: a mechanism for early adoption.
But let's face it: 6to4 has some ugly warts: packets typically have to travel as IPv4 packets far farther than the local ISP office. A typical 6to4 packet traversal is along the lines of:
IPv6 from your computer to your home router
IPv4 from your home router to either your tunnel broker or anycast 6to4 endpoint
(This step usually involves either an oversubscribed 6to4 endpoint, or an oversubscribed peering between ISP's.)
IPv6 from the 6to4 provider to an entirely different 6to4 router>
The destination 6to4 router then converts the packets back to IPv4, and shoots them to the destination home router.
(This step usually involves either an oversubscribed 6to4 endpoint, or an oversubscribed peering between ISP's.)
The destination home router then converts the packets from IPv4 back to IPv6, and onto the target machine
Not only does 6to4 add many unnecessary (and time-consuming steps), but network routing is much less efficient, which makes it even slower. I've yet to see a single 6to4 tunnel that had anything approaching the latency and bandwidth of the native IPv4. Having double (or more) of the latency, and considerably less bandwidth is a pretty poor user experience. In my mind, 6to4 tunnels are a hack that I'll be glad to be rid of, and one that normal users should never have to put up with.
Normal users shouldn't know or care about IPv6. Only we few should even have to think of a 6to4 tunnel, let alone use one.
For the "general case" internet user, the correct path is for the ISP's to provide native IPv6.
The real question is whether Apple is premature or simply "ahead of the curve" in deprecating 6to4 tunnels. I honestly feel the vast majority of users will never use 6to4 or its ilk - the transition will be from IPv4 only to a native dual stack - at which point the "removal" of 6to4 configuration is a moot point.
The Airport devices (and their firmware) have IPv6 support - that has never changed.
The changes sound very "Apple", actually. There's a famous story of the iDVD team having a whole set of slides ready to show user interaction. Steve Jobs walks in, doesn't take a single look at their presentation, and draws a window on the chalkboard. "This is your interface. You drag movies to the window, you click 'burn.' That's it."
There are two "latest" Airport Configuration Utiltities right now - 5.6 and 6.0. 6.0 is the "This is your interface, you click a button. That's it." interface. IPv6 "just works" if the Airport device is actually given IPv6 subnets & routes.
I'm personally not a fan of 6.0, but having actually used it, I'll share what I've found:
I've configured a network that provides full "Native" IPv6 and IPv4. I've hooked up the Airport in the network, so that it receives native IPv6 and IPv4 addresses & routing from an upstream router. Everything - both IPv6 and IPv4 "just work" with zero modification needed. As dual-stack native IPv6 & IPv4 is the model most ISP's have targeted; it seems that the Airport devices will "Just work" when ISP's decide to actually provide IPv6.
This also exposes the real issue: Nearly all of us only get native IPv4 from our ISP's - we have to use a 6to4 tunnel to get IPv6.
6to4 tunnels are best though as not food, but an alternative to starving - Some ISP's provide their own 6to4 routers; they are oversubscribed, and aren't 'network-local' - with packets often crossing the country a few times within the ISP's internal network just to get to their sole 6to4 router. Others use external 6to4 tunnel providers - and packets then must cross oversubscribed ISP peering points. In both cases, the result is similar: much higher latencies, much lower bandwidths, and less reliability.
All in all, it's a bad user experience, and 6to4 is a hack that normal users shouldn't have to deal with - it's a transition mechanism for early adopters like us, after all.
Nearly every other user, however, shouldn't care about IPv6, nor should they be forced to learn. A 6to4 tunnel should be (and is) unnecessary for nearly everyone. What is necessary is that when the ISP deploy native IPv6, their networking hardware should "just work". The user shouldn't ever know anything has changed.
From my own testing, that's exactly what will happen with the Airport devices.
There is really no excuse for the sorry state of affairs we are in. My Atari ST from a good 20 years ago boots and runs faster than a current PC, and does just as much.
Let's be honest, now: Your Atari ST doesn't do anywhere near as much. The ST can boot quickly because it doesn't actually do a whole lot. Back in the day, it was quite an accomplishment to format a disk and use a word processor at the same time. Multitasking isn't something the ST was ever asked to do. It had one bus to support - instead of having PCI, PCI Express, USB 1-3, Firewire... the list goes on and on.
So the question really is this: what determines if bloated and unnecessary things like USB, 3D Graphics, surround sound, or even asinine things like monitoring Twitter are necessary? The obvious answer is that the person buying it determines if it is necessary.
The problem is that the number of things that are necessary to the people buying the machines has grown faster than the ability to execute them.
... we allow bloat to continue. We should be *demanding* efficiency in code.
Runtime efficiency is important - but it's only a tiny sliver of system design.
Increased development time and cost of maintaining highly optimized code quickly balloons to the point the market is unwilling to bear, and you go out of business to somebody who delivered inefficient code sooner and at lower cost.
That specific drama has played itself over and over. Time to market matters. Development and maintenance costs matter. History has repeatedly shown that customers are far more willing to pay more to get new hardware now and run inefficient code than they are to wait - often for months - for code that will run efficiently on their hardware.
I work with supercomputers - where runtime costs are typically far larger than development costs - it costs more to run the system a few days than I get paid in a year. Execution efficiency is extremely important.
A singleminded pursuit of runtime efficiency also misses the entire point of a supercomputer: To get answers faster. You want the answer computed now. So the question is: Do we want to spend a huge amount of time optimizing the code - often months or even years longer, or do you just plug the inefficient, bloated code in, and let the computer chug away? Typically, you get the answer much faster by running inefficient code than waiting for optimizations to be developed and debugged.
The march of hardware moves so quickly that most of the software optimizations that were common "a few years ago" either don't work or offer no benefit when executed on new hardware - if you're lucky. If you aren't lucky, it'll run slower.
Is stuxnet now being used as an excuse for a good ol' fashioned witch hunt? Just accuse your workplace foes of espionage, get them hauled away, and step into the guy's shoes with a pay raise?
Grow up. Most people are not sysadmins. People who are not sysadmins and in a unix environment are most likely using Linux.
You seem to be more than happy to claim (with absolutely nothing to back up your claims) that only a tiny number of users actually care about network transparency, about the number of xBSD users using it as a desktop, and so on.
You are no more capable to speak for any group of people than I; making gradiose claims as if you speak for "the majority" does not give the impression of maturity.
You rant about sysadmins, but you know what? I'm not a sysadmin. I'm a normal Linux user; and every other "normal" Linux user I know - every single one - needs network transparent windowing for their day to day work. Is it a case of selection bias? Quite possibly. I'm only qualified to state my own observation - that nearly every one of the hundreds of Linux users I've ever interacted with want or need network transparency in the windowing system. Only a couple are sysadmins.
As a result, I obviously find it laughable to see anyone claim that only a fraction of a percent of desktop Linux users want or would find network transparency useful. I'd personally guess it's somewhere between a quarter and half of desktop Linux users.
As far as "just keep using X.org"... orphaned software isn't terribly useful. Distributions stop providing it, and orphaned software often won't even compile it in as little as a year, depending on the march of the toolchains. The forward looking thing to do is to petition the Wayland developers (many of whom are also Xorg developers) to provide network transparency. It's not an unreasonable request; since they are also Xorg developers, they're far better suited to designing an efficient protocol than nearly anybody else on the planet.
The penalty placed on those who don't use network transparency is exactly nothing. Network transparency will not in any way hurt those that don't need it; that's the entire point of dynamic libraries.
Wayland still offers X11, so applications that need X11 just don't move over to the new standard.
It has nothing to do with the *application* needing X11 transparency. It's what the *user* needs. It doesn't matter that X11 support exists if the app I need to use over the network is wayland only.
It's virtually certain that many Linux distributions (especially ubuntu) will have have compiled out X11 entirely - meaning that Qt at GTK applications that should have no problem using X11 (and operating over the network transparently) will be entirely unable to.
If you are a sysadmin gloating over your domain displayed in a 100-window screen session, Wayland is obviously not for you. It's for the rest of us, who are perfectly willing to give up network transparency to get a lighter, faster windowing system.
Hate to tell you this, but you're wrong on a couple of points:
1.) A lot of people absolutely *require* network transparency. By dumping network transparency, you're alienating the admins and developers who've brought Linux to the point it is today, and continue to support it. Network transparency costs nothing in terms of runtime speed or resources. If you're not using network transparency, no extra cycles are consumed. This has been true with X for ages. Alienating the admins who have been promoting Linux on the desktop at organizations worldwide isn't a good thing - you'll force them and their organizations to use something else (likely *BSD).
2.) "X is bloated and slow" is honestly the biggest load of crap I've seen in my years in computing. Have you ever looked to see the kind of resources required by "modern" technologies? Quartz uses a few times more resources than X11, and the Windows GUI is even worse. I really don't see how anyone can claim that X11 is hard on system resources. It may have been true twenty years ago, but twenty years ago, a megabyte was a huge amount of memory for a computer to have.
X uses considerably fewer resources than my web browser. X is using less than 0.5% of my three-year old system's memory. What, pray tell, is that extra fraction of a percent of memory going to buy *anything* in terms of 'lightness' or 'speed'? Nothing at all.
I'm willing to bet Wayland+Weston will use more RAM and more CPU cycles than X11 does. Given the "screw you community" view the project has to anything other than Linux, I really don't see how Wayland will succeed. Few projects do well when they alienate entire communities of developers.
VNC is going to work the same way it does with Windows or MacOSX which doesn't involve low level support. VNC is an alternative to Network transparency.
Excrement is an alternative to food. Gotcha.
The only redeemable thing about VNC is that it's better than nothing. That's a pitifully low bar. VNC is marginally better than having somebody take a picture of their screen with their camera, and text message it to you.
VNC has a horrible user experience, it's horrifically slow, and universally ugly - the only way to get it to "work" even half-reasonably is to compress the bitmaps so severely that the artifacts make text illegible.
If you increase the bandwidth used to the point VNC can operate with anything other than "please kill me" as its user experience, X11 will run rings around it.
If I had a dime for every time I've been bitten by not being able to copy & paste because of someone's VNC implementations, I'd be able to buy a yacht.
There's no reason that *real* network transparency shouldn't be provided.
X is long in the tooth; the X protocol can certainly be improved upon. Throwing out network transparency is a huge step backwards.
Guys like that auditor are wonderful data breaches.
It's probably for the best his company wasn't disclosed; with competence like that (and the data he's collecting), a hack would be simple and the consequences dire.
Slashdot Mirror
Note that for Emacs, a decade is just the blink of an eye.
I've heard that Emacs Makes A Computer Slow... but I didn't know it was that slow.
Verifying temperatures isn't generally that easy - mainly because what most systems are designed to measure isn't what most humans want to hear from it.
The first law of thermodynamics is we don't talk about thermodynamics.
Many monitoring packages typically fudge their numbers to some extent. It's a case of "A little inaccuracy can save a great deal of explanation."
The (vast majority) of people who even look at CPU temps are enthusiasts who think they know something about die thermals, but really have no fraking clue, other than "hot bad". A hard number is easy to understand - even if it's a lie or doesn't tell you anything that's actually useful.
Die temperatures (as measured by a thermal diode) can vary quite a bit compared to heatsink temperatures. Even then - move the probe to a different point on the heatsink, and the temp measured can vary even more. This means that comparing a thermal diode's temperature (ie. on-die in the GPU) vs. anything you can measure externally (via heatsink) is going to be a lot more trouble than it's worth -- and it's going to be different for every combination of die/heatsink/fan/chassis.
There are usually entirely different goals in temperature measurement. While a fixed temp is easy for a human to understand, a fixed temp isn't that great of a metric for a CPU's (or it's cooling system's) thermal health.
For example, Intel's PECI doesn't report absolute temperatures; it reports a negative value which represents the number of degrees until the core is "hot" - which isn't based on any fixed temperature. Some (wrongly) look at the CPU's max temp spec, and figure they can translate that to an actual temp.
In reality, it's like asking your wife "are you hot?" and then guessing what the temperature is from her reply. The result can vary depending on any of a number of external factors. More importantly, the number doesn't really matter to begin with. What matters is how your wife feels.
The "external factors" for a silicon die would be things like load, the volume, velocity, and temperature of the coolant air over the heatsink, heatsink size/geometry/material, airflow patterns in the chassis... Manufacturers (be they Intel, AMD, NVIDIA, or anybody else) don't have the luxury of controlling any of those variables, so they either have to design adaptive systems, or throw performance out the window in by throttling the core when they don't really have to.
AMD may not have the best drivers, but I dont recall any AMD drivers that allowed me to play games and fry eggs with the same piece of hardware like Nvidia.
You don't seem to have looked hard enough at the AMD drivers, or developed software that uses them.
I write management software for supercomputing clusters - and GPU's are one of the shiny things right now. Mainstream GPU drivers have hooks that let us do things that admins like to know about - monitor temps, fan speeds, voltages, etc.
Unfortunately, AMD's driver's aren't just bad. I'm not a lawyer, but there's a good chance they are criminally bad.
Fatal flaws that I know of:
* It's trivial to write a program that will shut off the GPU's cooling fan with the AMD drivers; as well as disabling any overtemp throttling. I'm honestly surprised malware hasn't been written to do this already. Either way, your eggs will be ready shortly. I hope the building doesn't burn down.
* This is a gripe on their Linux drivers, but it's fair game: AMD's own instructions explicitly state that to make GPU monitoring available to a monitoring daemon (or to make GPU crunching available to remote users), it's necessary to run "xhost +" as root.
Whiskey, Tango, Foxtrot
For those that don't know - runining "xhost +" as root isn't as bad as having an empty root password, but it's near the top of the list of batshit-stupid things to do. None of AMD's competitors require opening one of the biggest security holes possible just to use their product. What's worse: AMD's response is that they won't be doing anything about it for the forseeable future.
Other GPU makers aren't without problems - everybody has faults - but it speaks volumes that AMD has no intention of fixing a grave security bug in their drivers.
When you want to design an build a house, you don't start out by designing and building a car to park in the garage.
That's not even an analogy: The car isn't even part of the house. It can be removed or omitted, and doesn't change the properties or functionality of the house at all.
To use your house analogy, a touch screen would be like designing the roof for the house. Rip out the roof, and the house isn't a house anymore.
I don't really understand why you can't understand this: A touchscreen is just another part - just like a resistor, capacitor, switch, inductor, LED, etc. Nearly all electronics work involves connecting components together. Yes, a touch screen has many sub-components - but the same is true of every other electronic part, including something dead-simple like a circuit board or a resistor.
You read the touch screen's data sheet, and implement the interface. There are color touch screens for $30 that have workable interfaces; a 16-bit parallel bus for the graphics, a couple control pins, and four pins for touch sensing. No big deal; you can drive that with a DIP micro controller.
If you actually wanted to make a touch-screen interface for its own sake, you would want it somewhere you could show it off (like your pocket), not hidden in your furnace room.
At what point was showing off the project a design goal? If showing it off is your goal, then you're not doing the design for its own sake, but for the sake of showing off.
I seem to recall the OP's goal being "make an embedded device with a touchscreen." - not write a smartphone or tablet application, and not buy an already-working device.
I'm perfectly happy with a touchscreen design hidden in my furnace room. Having a sprinkler control system with a touch screen is pretty cool, and a lot less intimidating for my wife. There's a tremendous amount of personal satisfaction in knowing that I've made a reliable, user-friendly system.
If I'm doing something for its own sake, I'm more interested in the journey to get there than the end product. The end product is often just an excuse for the journey.
Your argument is like saying somebody shouldn't cook, because there's an abundance of restaurants and prepackaged, prepared food.
Some of us like designing hardware from components. We like designing circuits, laying out printed circuit boards (and fabricating them), component soldering - including things like toaster-oven reflow soldering. We like debugging wire protocols, using logic analyzers, and yes, programming microcontrollers.
Being able to say "yes, I can design products that use a touch screen" can be very helpful in a job interview.
Let's not forget that the patent system doesn't just cover electrical & programming tech.
It also covers chemical, pharma, materials, manufacturing, physical machines, etc.
It's a mess having one patent system to cover everything under the sun.
The problem is that there would be an even bigger mess if there were different rules and multiple categories.
Patents do have a useful purpose, even today. It does provide incentive to do long-term R&D.
The problems I see:
1.) Corporate Arrogance:
- Patent licenses are often far more expensive than they are worth.
- Companies decide it's cheaper to litigate than to license - and as often as not, they are right.
- "A good is worth exactly what its buyer is willing to pay" - when a federal patent lawsuit is the cheaper option for your customers, your good is overpriced.
2.) Parts of the law are written in a way that encourage lawsuits:
- There's no incentive to find out what other companies have patented; in fact, you are penalized for it. I understand the reasons why it's written that way, though.
3.) The patentability bar is too low.
Patents are generally seen as a good thing - they provide incentive for long-term R&D. It's not as apparent in the computer industry, but it is in others.
The problem is writing an effective law is not easy - it's harder than writing code that's completely free of bugs and security holes. The difference is there's tremendous pressure to just leave the bugs in place. "it worked in the past! It can't be wrong!" (i.e. the fallacy that nothing ever changes, and laws can't/shouldn't be changed.)
Or any of the legion of ham radio operators worldwide.
Hams know all too well that their transmitter can easily overpower their neighbor's TV reception.
I know when I did ham radio as a teen, some of the exam questions were about how to deal with neighbors who are angry that you're ruining their reception.
Really? When was the last time you were in a housing project? Did you take ANY time to get to know the poor? Or are you making blanket assumptions based on lame and uninformed propaganda?
Your statement positively oozes contempt for people you quite obviously have no clue about. In my mind, anyone who sneers at a human being because of their poverty is worse than a card-carrying KKK neo-nazi. It's every bit as prejudiced as the belief that a person's color has anything to do with their character.
I spent years working with the poor; I spent more time in the projects than many of the residents. I took the time to get to know them as human beings.
In my experience, their situation has absolutely nothing to do with not wanting to work. I get so sick of hearing ignorant pricks say some lame line like "work at McDonalds." There is no unlimited supply of jobs available anywhere. The poor want jobs - badly. They want to work, and do so when they can.
But you know what? The kinds of hours they have to work isn't sustainable by the human body. The body inevitably breaks down from the strain, and they eventually cannot physically go to work. I've regularly seen people work to the point they pass out, after which they are fired. I know because I paid for college by working at such a job. Naturally, the corporation provides no health care coverage, so there is no treatment or physical therapy to get them back into the work force. Workman's comp? Are you joking? You haven't seen corporate america at work.
I'm convinced those who are constantly whining about 'the lazy poor' understand a lot less about economics than the teenage dropouts they demonize.
I'd be interested in seeing how the Saleae 16 stacks up against the OpenBench Logic sniffer; they both seem to fit into the same niche, and both use the same Xilinx FPGA to measure the signals, so the capabilities have got to be similar I have an OLS, and so far, I'm pretty happy with it.
And along the same note, I wonder how the Beagle compares to the "Bus Pirate." The Bus Pirate supports 1-Wire, I2C, SPI, & JTAG, so at least on the surface it looks pretty good.
I know the OpenBench Logic Sniffer and Bus Pirate are fully "open-source" hardware & software; and are much less expensive - at $50 for the OLS, and $30 or so for the Bus Pirate.
But I have to agree with you - collecting the data is one thing, but sorting through it is what separates a toy from a tool.
I'd argue that an oscilloscope doesn't even fit the same niche as a logic analyzer.
Oscilloscopes are more for analog signals (and in the end, everything is an analog signal), while logic analyzers are for digital signals.
The Nano is a digital storage oscilloscope - which is no doubt useful. It shows continuous voltage levels over time, and is great for analog signals; it measures 0-10V at 1Msps, with 12-bits of resolution.
But a logic analyzer fits into a different niche; it really only measures "high" or "low", but across many channels (instead of 1 or 2 as in an oscilliscope).
The OpenBench Logic Sniffer, for example, measures:
- Up to 32 channels at 100 MHz
- Up to 16 channels at 200 MHz
- 1.8-5V, which covers most digital chips.
- costs $50 - almost half of the Nano's price.
They are clearly different tools, though. If I were measuring PPM coming out of a microcontroller (as in an arduino), I'd choose a Logic Analyzer over an oscilliscope.
To regain market share, RIM needs a product that will:
1. Be the BEST and most integrated social networking tool.
2. Be a WALLET by leveraging their existing encryption infrastructure.
No matter what gee-whiz bang they add to the hardware, RIM is still stuck with the features & API that the social networks provide to RIM - and every other platform.
Microsoft tried to go social with a couple of Windows phones - one was summarily canceled on the day of release. Microsoft tried again with Windows Phone 7, and was met with chirping crickets. I doubt RIM or anyone else would do better.
RIM's vaunted existing encryption and infrastructure isn't that special these days; it's certainly nothing that isn't provided by Google or iCloud.
Unfortunately, I think RIM had their one great idea over a decade ago, and have been resting on that ever since. The clock slowly ticked away - it was only a matter of time before RIM's products weren't that special anymore without some serious innovation - and another 'great idea.'
That day has come and gone; RIM ran out of time, and had nothing - literally nothing in the pipeline; their copies of the iPhone and iPad weren't just bad, they were comically bad. Their tablet couldn't even read email - the one thing you'd think RIM could get right.
... incident resulting in the dropping of the Great American Shithammer.
Which makes me wonder. Just how much american shit have we exported in the last decade?
Maybe we shouldn't have been wasting it by dumping it in latrines in Iraq and Afghanistan - to say nothing of our own public sewer systems.
We should have been collecting it so we could fill colorful balloons with it, and then drop them by the million over the cities of our enemies.
Daddy, Daddy! Look at all the pretty balloons they're dropping!
There. Now I can claim prior art for the idea.
I did the PC gaming rig thing for two decades. Add that to my computer engineering degree, and my profession making supercomputers. Don't make me laugh about "proper planning." I've dealt with more types and generations of hardware than most people have in their worst nightmares - I know what works, and what doesn't. I've had to clean up other people's messes for ages.
I got sick of dealing with it all.
To expand on your list:
* No need to worry about upgrading the video card
* No need to worry about upgrading RAM
* No need to worry about upgrading the Motherboard
* No need to worry about upgrading the CPU
* No need to worry about upgrading the Disk Drive
* No need to worry about upgrading any peripherals
* No worrying about the massive money pit called a "gaming rig"
* No worrying that you're "missing out" by not constantly upgrading your system
* No worry about losing a competitive advantage by not upgrading your system
* No worrying about compatibility
I used to be a big PC gamer (for about 20 years, actually), but got tired of the constant expense & fight with the hardware, software, and drivers to keep my system upgraded to the point I could play the games I wanted to. I grew tired of sitting at my gaming PC when I got home from work - in essentialy the same posture & environment as my cubicle.
Consoles remove most of that problem. Wanna play CoD while laying on your side? With a console, it's no problem. With a gaming rig, it's not so easy, if at all. Is a new "must have" game coming out? There's no need to upgrade the system to play it; just pop in the disc and rock.
The bottom line is consoles are far cheaper, I don't have to deal with "spec fanbois" constantly boasting (or moaning) about hardware in their system, and consoles "just work".
Jesus, after all, wasn't caucasian, gave out free food & healthcare, and said the rich have virtually no chance of getting to heaven.
He's clearly not representative of our nation's Christian foundation.
Ayn Rand, on the other hand, stated that altruism is the heart of all evils, and Jesus's teachings would lead to the enslavement of mankind.
So clearly a good Christian should follow the example of Ayn Rand, and not Jesus.
There is a lot of confusion here from people who have obviously never configured Airport devices.
Most routers provide a web interface. The configuration interface is part of the router's firmware, and it can be assumed that if the configuration interface doesn't have a setting, it doesn't exist.
This is not the case with Airport devices.
Airport devices do not provide a web interface; the only way to configure them is through the "Airport Configuration Utility" which runs as an application on your PC, Mac, or iOS device. The Airport device's firmware hasn't changed - it still provides the same functionality it always has.
Second, there is a difference between between native IPv6 and running a 6to4 tunnel. One is "real" IPv6, the other is a hack for early adopters who want to gain experience with IPv6, even though their ISP doesn't provide it.
The Airport firmware hasn't removed any IPv6 support at all. As far as I can tell (and I've set it up on my home network), if an Airport device is given native IPv6 addresses & routing, it uses them and passes them along to devices that connect to the Airport network. "It just works."
The catch is that you cannot configure a 6to4 tunnel using Airport Configuration Utility 6. A 6to4 tunnel is the only way to get IPv6 for most of us, so many cry that the sky falling, etc. (Even though Apple released a new version of ACU - 5.6 - the same day as 6.0 - and 5.6 still has 6to4 tunnel configuration)
For those of us geeks that want IPv6, 6to4 is fine; we're using it for exactly the purpose it was designed for: a mechanism for early adoption.
But let's face it: 6to4 has some ugly warts: packets typically have to travel as IPv4 packets far farther than the local ISP office. A typical 6to4 packet traversal is along the lines of:
Not only does 6to4 add many unnecessary (and time-consuming steps), but network routing is much less efficient, which makes it even slower. I've yet to see a single 6to4 tunnel that had anything approaching the latency and bandwidth of the native IPv4. Having double (or more) of the latency, and considerably less bandwidth is a pretty poor user experience. In my mind, 6to4 tunnels are a hack that I'll be glad to be rid of, and one that normal users should never have to put up with.
Normal users shouldn't know or care about IPv6. Only we few should even have to think of a 6to4 tunnel, let alone use one.
For the "general case" internet user, the correct path is for the ISP's to provide native IPv6.
The real question is whether Apple is premature or simply "ahead of the curve" in deprecating 6to4 tunnels. I honestly feel the vast majority of users will never use 6to4 or its ilk - the transition will be from IPv4 only to a native dual stack - at which point the "removal" of 6to4 configuration is a moot point.
The Airport devices (and their firmware) have IPv6 support - that has never changed.
The changes sound very "Apple", actually. There's a famous story of the iDVD team having a whole set of slides ready to show user interaction. Steve Jobs walks in, doesn't take a single look at their presentation, and draws a window on the chalkboard. "This is your interface. You drag movies to the window, you click 'burn.' That's it."
There are two "latest" Airport Configuration Utiltities right now - 5.6 and 6.0. 6.0 is the "This is your interface, you click a button. That's it." interface. IPv6 "just works" if the Airport device is actually given IPv6 subnets & routes.
I'm personally not a fan of 6.0, but having actually used it, I'll share what I've found:
I've configured a network that provides full "Native" IPv6 and IPv4. I've hooked up the Airport in the network, so that it receives native IPv6 and IPv4 addresses & routing from an upstream router. Everything - both IPv6 and IPv4 "just work" with zero modification needed. As dual-stack native IPv6 & IPv4 is the model most ISP's have targeted; it seems that the Airport devices will "Just work" when ISP's decide to actually provide IPv6.
This also exposes the real issue: Nearly all of us only get native IPv4 from our ISP's - we have to use a 6to4 tunnel to get IPv6.
6to4 tunnels are best though as not food, but an alternative to starving - Some ISP's provide their own 6to4 routers; they are oversubscribed, and aren't 'network-local' - with packets often crossing the country a few times within the ISP's internal network just to get to their sole 6to4 router. Others use external 6to4 tunnel providers - and packets then must cross oversubscribed ISP peering points. In both cases, the result is similar: much higher latencies, much lower bandwidths, and less reliability.
All in all, it's a bad user experience, and 6to4 is a hack that normal users shouldn't have to deal with - it's a transition mechanism for early adopters like us, after all.
Nearly every other user, however, shouldn't care about IPv6, nor should they be forced to learn. A 6to4 tunnel should be (and is) unnecessary for nearly everyone. What is necessary is that when the ISP deploy native IPv6, their networking hardware should "just work". The user shouldn't ever know anything has changed.
From my own testing, that's exactly what will happen with the Airport devices.
There is really no excuse for the sorry state of affairs we are in. My Atari ST from a good 20 years ago boots and runs faster than a current PC, and does just as much.
Let's be honest, now: Your Atari ST doesn't do anywhere near as much. The ST can boot quickly because it doesn't actually do a whole lot. Back in the day, it was quite an accomplishment to format a disk and use a word processor at the same time. Multitasking isn't something the ST was ever asked to do. It had one bus to support - instead of having PCI, PCI Express, USB 1-3, Firewire... the list goes on and on.
So the question really is this: what determines if bloated and unnecessary things like USB, 3D Graphics, surround sound, or even asinine things like monitoring Twitter are necessary? The obvious answer is that the person buying it determines if it is necessary.
The problem is that the number of things that are necessary to the people buying the machines has grown faster than the ability to execute them.
... we allow bloat to continue. We should be *demanding* efficiency in code.
Runtime efficiency is important - but it's only a tiny sliver of system design.
Increased development time and cost of maintaining highly optimized code quickly balloons to the point the market is unwilling to bear, and you go out of business to somebody who delivered inefficient code sooner and at lower cost.
That specific drama has played itself over and over. Time to market matters. Development and maintenance costs matter. History has repeatedly shown that customers are far more willing to pay more to get new hardware now and run inefficient code than they are to wait - often for months - for code that will run efficiently on their hardware.
I work with supercomputers - where runtime costs are typically far larger than development costs - it costs more to run the system a few days than I get paid in a year. Execution efficiency is extremely important.
A singleminded pursuit of runtime efficiency also misses the entire point of a supercomputer: To get answers faster. You want the answer computed now. So the question is: Do we want to spend a huge amount of time optimizing the code - often months or even years longer, or do you just plug the inefficient, bloated code in, and let the computer chug away? Typically, you get the answer much faster by running inefficient code than waiting for optimizations to be developed and debugged.
The march of hardware moves so quickly that most of the software optimizations that were common "a few years ago" either don't work or offer no benefit when executed on new hardware - if you're lucky. If you aren't lucky, it'll run slower.
Is stuxnet now being used as an excuse for a good ol' fashioned witch hunt? Just accuse your workplace foes of espionage, get them hauled away, and step into the guy's shoes with a pay raise?
Grow up. Most people are not sysadmins. People who are not sysadmins and in a unix environment are most likely using Linux.
You seem to be more than happy to claim (with absolutely nothing to back up your claims) that only a tiny number of users actually care about network transparency, about the number of xBSD users using it as a desktop, and so on.
You are no more capable to speak for any group of people than I; making gradiose claims as if you speak for "the majority" does not give the impression of maturity.
You rant about sysadmins, but you know what? I'm not a sysadmin. I'm a normal Linux user; and every other "normal" Linux user I know - every single one - needs network transparent windowing for their day to day work. Is it a case of selection bias? Quite possibly. I'm only qualified to state my own observation - that nearly every one of the hundreds of Linux users I've ever interacted with want or need network transparency in the windowing system. Only a couple are sysadmins.
As a result, I obviously find it laughable to see anyone claim that only a fraction of a percent of desktop Linux users want or would find network transparency useful. I'd personally guess it's somewhere between a quarter and half of desktop Linux users.
As far as "just keep using X.org"... orphaned software isn't terribly useful. Distributions stop providing it, and orphaned software often won't even compile it in as little as a year, depending on the march of the toolchains. The forward looking thing to do is to petition the Wayland developers (many of whom are also Xorg developers) to provide network transparency. It's not an unreasonable request; since they are also Xorg developers, they're far better suited to designing an efficient protocol than nearly anybody else on the planet.
The penalty placed on those who don't use network transparency is exactly nothing. Network transparency will not in any way hurt those that don't need it; that's the entire point of dynamic libraries.
Wayland still offers X11, so applications that need X11 just don't move over to the new standard.
It has nothing to do with the *application* needing X11 transparency. It's what the *user* needs. It doesn't matter that X11 support exists if the app I need to use over the network is wayland only.
It's virtually certain that many Linux distributions (especially ubuntu) will have have compiled out X11 entirely - meaning that Qt at GTK applications that should have no problem using X11 (and operating over the network transparently) will be entirely unable to.
If you are a sysadmin gloating over your domain displayed in a 100-window screen session, Wayland is obviously not for you. It's for the rest of us, who are perfectly willing to give up network transparency to get a lighter, faster windowing system.
Hate to tell you this, but you're wrong on a couple of points:
1.) A lot of people absolutely *require* network transparency. By dumping network transparency, you're alienating the admins and developers who've brought Linux to the point it is today, and continue to support it. Network transparency costs nothing in terms of runtime speed or resources. If you're not using network transparency, no extra cycles are consumed. This has been true with X for ages. Alienating the admins who have been promoting Linux on the desktop at organizations worldwide isn't a good thing - you'll force them and their organizations to use something else (likely *BSD).
2.) "X is bloated and slow" is honestly the biggest load of crap I've seen in my years in computing. Have you ever looked to see the kind of resources required by "modern" technologies? Quartz uses a few times more resources than X11, and the Windows GUI is even worse. I really don't see how anyone can claim that X11 is hard on system resources. It may have been true twenty years ago, but twenty years ago, a megabyte was a huge amount of memory for a computer to have.
X uses considerably fewer resources than my web browser. X is using less than 0.5% of my three-year old system's memory. What, pray tell, is that extra fraction of a percent of memory going to buy *anything* in terms of 'lightness' or 'speed'? Nothing at all.
I'm willing to bet Wayland+Weston will use more RAM and more CPU cycles than X11 does. Given the "screw you community" view the project has to anything other than Linux, I really don't see how Wayland will succeed. Few projects do well when they alienate entire communities of developers.
VNC is going to work the same way it does with Windows or MacOSX which doesn't involve low level support. VNC is an alternative to Network transparency.
Excrement is an alternative to food. Gotcha.
The only redeemable thing about VNC is that it's better than nothing. That's a pitifully low bar. VNC is marginally better than having somebody take a picture of their screen with their camera, and text message it to you.
VNC has a horrible user experience, it's horrifically slow, and universally ugly - the only way to get it to "work" even half-reasonably is to compress the bitmaps so severely that the artifacts make text illegible.
If you increase the bandwidth used to the point VNC can operate with anything other than "please kill me" as its user experience, X11 will run rings around it.
If I had a dime for every time I've been bitten by not being able to copy & paste because of someone's VNC implementations, I'd be able to buy a yacht.
There's no reason that *real* network transparency shouldn't be provided.
X is long in the tooth; the X protocol can certainly be improved upon. Throwing out network transparency is a huge step backwards.
I enjoyed that read; thanks for the link.
Guys like that auditor are wonderful data breaches.
It's probably for the best his company wasn't disclosed; with competence like that (and the data he's collecting), a hack would be simple and the consequences dire.