Because "It's Simple! All You Have To Do Is..."
Not just managers. Even working for yourself won't save you. Customers as well.
Because "It's Simple! All You Have To Do Is..."
Not just managers. Even working for yourself won't save you. Customers as well.
Brings to mind the Maxell ad where the guy is sitting in the chair, hair blown back by the JBL-L100 in front of him.
Imagine the paper tapes instead of the L100. Except no hair would be blowing back, and I suspect the fellow would be asleep. Other than that, exactly the same.
To answer your question about connectivity, the device has 10/100 Ethernet with the Linux networking stack built in.
That's excellent. Did you build your own protocol, or did you use the mechanism RFSPACE, Andrus, AFEDRI and the various USB-to-Ethernet servers have established?
I try -- hard -- to support all ethernet based SDRs for which I can obtain protocol information.
It also has USB-OTG, and I already know WiFi and USB Sound Cards work with no additional work.
Sound card I/Q is no problem for SdrDx -- that gets the RF in, and of course I support that. The problem with the rest is controlling the SDR's settings: center frequency, attenuator, sample rate, and so on. This is because of the radical differences in USB interfacing from platform to platform.
Having said that, if you've got a working command line utility that talks to the control systems on your SDR, then SdrDx emits information via TCP that can be used to drive the command line client from a script. We've pulled this off with the Peabody and Softrock SDRs pretty well. Again, though, we run into the issue of which platform(s) the utility is available for, seeing as how they'd have to be radically different from one another.
I think this is because in the olden days having CRLF meant being able to dump a raw text file to a printing device. Unix had a tty driver that could handle adding the missing CR. CP/M and DOS didn't have any such thing. That doesn't mean I haven't spent 20+ years being annoyed by CRLF though.
That's not it, CRLF was a feature. How do you make strike-through text on a type-wheel printer? It automatically advances to the next position and it only has a fixed number of characters, you don't double it with strikethrough-a in addition to regular a. So you send a CR - carriage return - to return to first position, space your way over to the text to be striked out and make a ------- over it before you CRLF to the next line. And you have no idea how old knowing that makes me feel.
Unfortunately most of the projects I've been on are of the "We want to replace old system A and make a new system B that also has features X, Y, Z" variety. What they want from the new system is usually okay, it's somewhat documented already, you've identified some stakeholders, you can show them prototypes, you can ask for clarifications and their testing validates the feature. Developing new code for genuinely new features is actually quite easy and fun.
The old system on the other hand is more like software archaeology, nobody really seems to have the specs - or maybe a spec 1.0 from 10 years ago that's got nothing to do with reality - and if you're replacing it it's probably because it's crap, uncommented code in an arcane language with poor frameworks and third party components. So you dig and keep digging and try to implement something similar without knowing what's a feature and what's a bug, who'll come yelling if you break something or features nobody told you about and you weren't aware anyone was using disappear.
I had a bit of an epiphany today at work when i finally found out how structure a major piece of the redo I'm working on and I've so far spent ~2 months digging through that code. From a similar job I was doing in another area I thought maybe 2-3 months total, now I'm guessing it'll be 6-12 because of all the rework I have to make and every apparently simple thing has exceptions and special cases. It's wasn't my bad estimation, it's that the conditions are entirely different. Like comparing travel speed for a walk in the park to chopping your way through a dense jungle.
Good managers get my best guess.
Bad managers get my worst case.
Horrible managers get my resignation.
It's not great. It's only good for staunch advocates who refuse to run any other operating system. Linux still isn't good enough for joe sixpack to run it as a daily driver. Until they get joe sixpack on board, it'll forever be a niche product without enough inroads to support a gaming ecosystem. (...) OS X has more of a chance at becoming a capable gaming OS than Linux does, and that's really saying something.
Except for cost. That's what powered the Android drive, it wasn't the technical superiority. There's probably more people gaming on phones and tablets than any other platform when you count Angry Birds, Candy Crush and such. Chromebooks running on Linux also seem to sell reasonably well for the same reason. If Valve can get a a range of steamboxes out there to sell to everything from a $99 box to sell freemium + $1-5 games to a $999 gaming rig to people who don't really care about having a desktop anymore with their tablet/convertible covering those needs there's probably a market for gaming boxes.
It does of course assume that you commit enough to get it off the ground. Nobody wanted to code for Android either before it got popular. And if Valve is backing off now that the Microsoft Store doesn't seem that big a threat after all, it might take many years. But Linux is well propped up by servers, supercomputers, embedded, cell phones, tables, chromebooks... it's not going away. Particularly not in the direction we're going with more cloud, less local it's certainly not going to get worse.
The driving force behind Mesa is Intel, they're certainly not going away. Pretty soon they'll hit the big OpenGL 4.0 and it seems almost all the prerequisities for 4.1 and 4.2 are done once they get over that hurdle. And they certainly want to keep their OpenGL ES current if they want to play in the x86 smartphone/tablet market. AMD also apparently like their open source driver for embedded/custom projects, less legal hurdles for customers who want full control. So maybe they don't win, but I don't see how they could lose much terrain either.
Built one almost like it, but with a 35W Core i7 4765T. It's not exactly a cheap machine though, for a HTPC it's way overkill. You can get a lot cheaper to play 1080p BluRays and probably won't be enough when 4K BluRay arrives, 3840x2160x60fps 10-bit HEVC decoding will need new, dedicated chips.
People complained about the playschool look of XP and hated all the chrome. Those same users swore by XP after Vista came out, and will adapt to metro the same.
Guilty as charged, eventually I had to move off 2k for XP. Skipped Vista (went on a Linux hiatus), got 7, skipping 8.x but Win10 looks like the next usable version. Until either WINE is just as good as the real thing or most games are cross-platform I'll probably be stuck with a box with a semi-recent version of Windows. Currently the WINE rating of the game I play the most is garbage.
You haven't lived until you've seen a centerfold spread out over six feet of multiple strips of punched paper tape.
What's the point of a fancy SDR on the lower bands though? At least in the States most of the amateur bands with any kind of useful propagation are so narrow that one of the brain dead simple sound card SDR rigs can cover the majority of your band of choice.
This is going to be long-winded; there's quite a bit to cover. Sorry.
Cover, yes. Cover well, no. You need lots of bit depth for adequate dynamic range without filters, bit depth almost no one offers, and if you don't have adequate bit depth, then you really need front end filtering and probably a stepped attenuator as well. You need EM protection because HF antennas tend to be large and prone to large induced voltages. You need good frequency linearity if you want to use the SDR to get accurate measurements (even the s-meter.) For the ham bands, it's also nice if the SDR supports a sample rate of 400 khz or better, which is tough for a sound card SDR. Then there is frequency accuracy and stability, not to mention external reference sources (there all kinds of cool things you can do with a very stable SDR, like this AM graveyard band carrier forest), and then we get into multiple front ends for diversity reception and noise reduction. If you want to remote the SDR for any reason, you really need ethernet, and if you need ethernet, you need some smarts. And you need ethernet anyway, because USB bloody sucks (speaking as a cross-platform developer.) So If you want a good SDR, you just don't end up with a "brain dead simple" SDR.
As to narrow ham bands in the HF range, well, not really. 160 meters is 200 kHz. 80 meters is 500 kHz. 20 meters is 350 KHz. 15 meters is 450 kHz. 10 meters is 1.7 MHz. The WARC bands are all pretty tiny. Also, for SWL, some of those are quite wide, and even more so if you include the out of band regions where the pirates are. Pirates being quite unpredictable, you want them in the spectrum so you can see them when they pop up, so bandwidth is quite relevant if they are of interest (personally, I find them fascinating.) Come to that, if you want to see what overall prop/activity is looking like, you need 30 MHz of bandwidth to do it live.
I will grant you that someday, we may be able to put a 48 bit, multiple Gs/s A/D on a chip with a full ethernet interface cheap enough for anyone to own; but not right now. Until that day, good SDRs will not be "brain dead simple."
More on frequency range: If you want to use the SDR for a panadaptor for an existing receiver (very common use), then it has to cover one of the IF frequencies and associated bandwidth of the receiver, which tends to be in the HF range (not always, though.) Then there are cray-cray folk like myself; among other things, I use my SDR to monitor bats in our attic. To do that, the SDR has to be able to do a good job with the first 100 KHz, also true of experimentation with sonar and other audio ranging and detecting tech.
I'm not saying there isn't stuff up higher than HF; of course there is. Some of the really cool stuff (wifi, for instance) is as high as 5 GHz. Satellites, public utilities, etc. Any motion video needs to be up pretty high (but it also needs very significant bandwidth.) But HF has a huge amount of interest, it's where most hams actually hang out, and as it's a very challenging reception environment, higher end designs are of great interest. So are hackable designs one can get at. For instance, if you built yourself a multi-stage filter bank for the various HF bands, you could have them switch automatically as you tune. Likewise you could control add-on attenuators, RF preamps, and switchable transverters (which can give a nominally lower freq range SDR excellent access to higher bands.)
I have a variety of SDRs, and switching is simply a matter of prodding a menu. I have access from about 1 Hz to 3 GHz across the group, with varying features as described above. In the end, as HF is so very active, that's where I usually end up listening. Although I'm an extra and have a full station, I do a lot more listening than transmitting. In the day, I lurk on 20 meters and up, though again as the sunspot count drops, that'll go back to only 20 meters. In the evening, 40 through 160 come alive, as well as many of the SW bands, and it's DX time, trying to catch the low power African and South American stations.
I think it's fair to say that most hams are, to coin a usage, "HF hams" first, and "VHF and above hams" second, if at all. VHF never offered much in terms of DX contacts or reliable prop events, so it was always about just communicating. With cellphones, that hook went away, and I'm guessing that's what accounts for the dead 2m and 70cm bands. But the HF bands are busy, and the number of hams keeps growing... so that leads me to think that an SDR aimed at hams can really use low band capability.
PS - I have VHF and UHF in the car and several units at home, plus an HT I carry in my man-bag (ie, purse.) I have a 14 element 2m beam. I can hit about eight repeaters from here, covering thousands of square miles. I hear *nothing* at home. I'm not hearing any VHF packet any longer, either. My lonely packet BBS beacon squirts out there by itself, no visitors and no digipeating and it has been that way for I don't even know how long. Trips to the cities nearest me result in dead silence on the calling frequencies and local repeaters, though I have to admit I don't make any calls myself -- I'm just curious so I listen.
Anyway, it's just one guy's opinion / anecdote, it isn't data, you have to listen to your own area and draw your own conclusions. Perhaps it's just Montana and surrounds. It certainly won't hurt anyone if I don't use a particular SDR. It'll have an effect if I don't support it, though, so hopefully, frequency range of 50-1000 or not, it has a protocol-compliant ethernet interface or some kindhearted person writes a USB-to-ethernet server on at least one platform so I can do so.
Most hams (including myself) are interested in HF (and others are interested in SWL and the new below-AM BCB ham frequencies.)
50 MHz means 6 meters and above -- basically, nothing that has any regularly occurring usable propagation modes. Many of these upper bands are almost dead -- I've not heard anyone on 2 meters or 70 cm around here in the last year -- but 10 through 160 meters (28 MHz through 1.8 MHz) are busy as heck, and of course all the SW spectrum in between.
Worse, we're almost certain to be about to slide down the sunspot curve, making the already mostly dead-by-choice bands completely dead-by-nature, propagation-wise.
RFSPACE's upcoming new unit is
Then there's funcube dongle pro plus... 50 khz through 1.8 GHz, albeit without adequate filtering up front. But it's reasonably cheap, so there's that. (and I already supported it, PITA though it was, so it's not subject to the no-more-USB-devices rule.)
Well, whatever they end up with, I sure hope it's ethernet-connected and uses the standard SDR protocol as do Andrus, AFEDRI and RFSPACE. I've supported my last black sheep USB device (every darned OS has radically different USB interfacing and requirements... building my free cross-platform SDR software is most tricky with regard to USB issues. Ethernet, by comparison, is almost identical on all platforms -- the same SDR protocol / interfacing code works fine across linux, Windows and OS X.)
Keep the Jehovahs and Mormons from getting in the house. Bonus if it can hold off people pushing meritless products. But I repeat myself.
As for serving drinks or drugs, the damn things should do what they're told. I don't need robots to take agency from me. Lard knows the frigging government is spending more than enough effort on that already. For me personally, all I have to say is "I already have (had) a mother, and her last bit of authority over me expired in 1977."
First time a (non-conscious) robot refused to do what I told it to, presuming only it was within its comprehension and skill set, I think I'd take a hammer to it.
Or, "Don't take life too seriously... it's not like it's permanent."
At that age it's usually not a problem, you're far more likely to do something reckless and stupid that will have consequences for the rest of your life. I'd at the very least temper it with a bit of "Enjoy today, plan for tomorrow". Sure, life might throw you a curve ball but if act like every day is your last the odds are pretty good that you're wrong and have to live with yesterday.
Look. The only reason you wouldn't be able to keep your insurance that the ACA could even *vaguely* be named responsible for is if it was so bad that it didn't meet the minimum standards of the ACA, and your insurance company didn't upgrade the policy accordingly -- most likely, they cancelled it in favor of new policies that *did* meet the minimum requirements. The whole *point* of the ACA was to see to it that people were *sufficiently* insured.
Otherwise, the only reasons you would lose your current insurance would be if the insurance company cancelled your policy -- and in that case, the blame lands squarely on the insurance company; or your employer decided to take the opportunity to cut your benefits and blame it on the ACA. In that case, look to your employer.
As for your doctor, the only ACA-related reason you might not be able to keep your doctor is if they don't bother to register with the pool you chose -- and all you have to do there is tell your doctor which one it is. And if they fail to register, you can blame your doctor. My doctor did the right thing, and she's still my doctor. I specifically asked, and she said there was almost nothing to it.
Now, let's look this issue right in the face. Are there conditions where you couldn't keep your doctor? Sure. For instance, if your doctor got run over by a bus. Or retired. Or committed suicide. Or moved to Botswana. Or switched jobs. So "Obama lied", right? But of course, if you're a sane person and not trying to shill your way through a bout of Obama-hate, you would understand that there will be some exceptions, and generally, they're going to be related to the doctor's circumstance -- just as the bus incident would be. Because there isn't one damn thing in the ACA that says "this here doctor can't be used."
As with the previous poster, my circumstances were enormously improved by the ACA. I did get to keep my doctor (it was no problem at all, she just did a little paperwork, that was it) and my coverage is now excellent.
Is everything perfect? No. Republicans are blocking the medicaid expansion here, so many no- and low-income individuals who were intended to be covered by the ACA, aren't. While this goes on, the taxes we paid here to cover them go to another state as the already-allocated funds are disbursed elsewhere. Consequently, our medical and insurance costs here are rising because we are paying the hospitals for uncompensated care for people who should have been covered, and for which the funds were already allocated.
"Being against torture ought to be sort of a multipartisan thing." -- Karl Lehenbauer, as amended by Jeff Daiell, a Libertarian