Huh - guess not. I know they have a large office of some sort out there, though - some of their hiring ads bleed over out here. Dentrix support is also based out of SLC (Henry Schein?); used to call out there pretty frequently when I was doing IG support for dental offices.
The University of Utah was one of the original ARPANET nodes back in the '70s, so there's been some tech out there for a while now.
Speaking as a Reno resident (It's Sacramento, only with hookers and blackjack!), I don't like Sacramento's chances, and it's not because I think Reno's chances are any better. Part of the problem is that there won't be a "next Bay Area" - not just one, anyway. The Bay Area's preeminence in the tech industry was kind of a fluke, which resulted from a combination of various factors (strong academic interest from Stanford and Cal, defense industries sprouting up in the area, good weather, and so on). These days, the tech industry is decentralizing, which is why you have "tech corridors" in places like Raleigh-Durham, Austin, Salt Lake City (Symantec is based there), Las Vegas (Zappos), Seattle, Portland (thanks, cheap hydroelectric power!), Los Angeles ("Silicon Beach" - I remember when Venice was a ghetto), Boston... and these are just the places in this country.
The other part of the problem is that Sacramento's biggest claims to fame at this point are that it's the state capital of California (*shrug*) and it's kind of close to the Bay Area (so is Vallejo, Vacaville and Antioch). The climate is miserable (think Texas weather, only with a little less humidity, no hurricanes and without the weird bugs), the neighborhoods are extremely hit-and-miss, the culture is getting better but is still more or less non-existent, California's tax and business codes are pretty obnoxious, the physical infrastructure in Sacramento isn't quite Stockton bad but there's definitely room for improvement... yeah. Sacramento's not bad, but it's not good, either.
Don't get me wrong, I think Sacramento will get some startups to set up shop there. Some of them will probably succeed. I don't think they're going to take over the world out there, though. Venture capitalists would rather go to Denver, Seattle, Portland or Las Vegas than Sacramento, and if you're going by plane, you're not saving that much time by going to Sacramento over either of those other places.
This is actually a good thing for PC-BSD for a variety of reasons. First, KDE's support for BSD is spotty - try mounting NTFS volumes using Dolphin in PC-BSD. You can't because KDE uses Linux-style mount options instead of BSD's. Also, KDE is (L)GPL, which BSD has been trying to avoid lately (hence Clang, LLVM, etc.).
I'm concerned that iXsystems and the community is biting off a bit more than they can chew - Canonical's having issues getting Unity out the door and, though I don't have either of their financials in front of me, my assumption would be that Canonical is a much bigger company with a much bigger community of developers behind them. However, if PC-BSD is going to get the stability and ease of use that's necessary to be a compelling desktop alternative for all but a few hobby enthusiasts, they're either going to have to maintain a BSD-friendly port of KDE or roll their own desktop manager.
There's also the issue of the existing infrastructure, versus how many people are out on the playa. Figure attendance is roughly 50,000 people or so, with an average of two people per vehicle. That's up to 25,000 vehicles leaving at a BLM-mandated 1,000/hour - a mandate, by the way, created to ensure that the two-lane road from Gerlach to I-80 still has some room to let the natives, both in Gerlach and "downstream" in Pyramid Lake", actually get out of their driveways and go somewhere that day. Do the math and some people are going to wait for a long, long, long time.
For those of you from Europe or those just generally not from the area, here's what's basically happening:
There is only one paved road to the Black Rock Desert - Nevada State Route 447 - which is only useful for most people if you take it heading southbound since that's the fastest way to an interstate (that's American for "large freeway") and is also the only direct route to Reno (nearest major airport) and the Bay Area. The total population served by this road is maybe 1,000 (I'm feeling generous), so the road is built accordingly - it's a two-lane highway that's generally straight thanks to the local geography but makes a rather firm point to go right through the middle of what habitation there is in the area (notably, Nixon and Wadsworth). The few towns served by the highway are consequently bisected by it - thus, if the highway gets overwhelmed, it's impossible for residents of the town to cross the street. Also, adding insult to injury, there's not a tremendous amount of freeway or onramp capacity once the highway reaches the freeway (no cloverleaf or anything), so excessive oncoming traffic can cause localized traffic issues on the freeway, too.
In short, Burning Man needs to somehow evacuate over 50,000 people using infrastructure built for less than 1,000 within 24 hours, and do in a way that doesn't paralyze the lives of every single town in the area. No matter how you look at that problem, people are going to have to wait - the only question is whether people are waiting with their keys in the ignition, whether they're waiting for their license plate number to come up, or some other means of queue management. It's either that or try to convince everyone to drive through Cedarville and Alturas to go home, not that they're equipped to deal with any significant traffic themselves.
RDP? SSH tunnels? Blasphemy. If you're using an SSH tunnel, all you need to do after that is enable WinRM, hit the remote cmd console, download a VNC server using BITSADMIN, and then go from there. Bonus points if you somehow manage to rope PowerShell connection and session objects into the mix.
Seriously though, TeamViewer is fine. The point of LogMeIn was that, if you needed remote access to another user's PC but they weren't technically savvy, you could walk them through it without too much trouble. SSH tunnels and proper VPNs are certainly preferable if you're in charge of both ends of the connection, but if you're not, TeamViewer, Jump Desktop, and the like get the job done without too much fuss.
Assuming the schema matches. Which, by the way, is an extremely bold assumption when you're dealing with pulling data out of a custom Access solution cobbled together over the past decade and pushing it into an out-of-the-box solution.
Having seen a few custom Access jobs in my time, I can tell you first-hand that, more often than not, you're lucky if the data is normalized, much less organized in any sane, sensible way. I've seen tables where there are "Serial Number 1", "Serial Number 2", and "Serial Number 3" fields, for example, because "nobody has more than three pieces of equipment". So, now you're faced with having to get that data halfway normalized, or at least document how you could normalize it, and then you have to map it up against the new solution's schema and hope and pray they have a set of tables that are designed to hold the data you're looking for.
You wouldn't - but you'd really prefer to not use NetBIOS names under any circumstances. Otherwise, SERVER1 is always going to have to resolve somewhere, regardless of domain, regardless of network topology, and that somewhere better be where the database expects to find useful data.
Having worked for a smaller company that could only afford a one person IT department, I agree that it doesn't make sense paying for a second full time person to sit around and stare at the primary sysadmin while they do their job. Frankly, in most companies with one person IT departments, work load is somewhat inconsistent to begin with - oftentimes there's just enough work to do where it would cost more to bring in a part-time consultant to do 4 hours of work that day than to pay the full time sysadmin to do 4 hours of work and then read Slashdot for the other 4. That problem would only get worse if you had to pay for an "understudy".
Thankfully, there's a really easy way to manage that, even for smaller companies. Bring in a part-time consultant periodically (say, for a couple hours every month) as an insurance policy. For the brief period they're there, have them focus on documentation and chatting up the sysadmin. As an added bonus, maybe have them check backups, server logs and the like to ensure the sysadmin isn't falling asleep at their desk. Another bonus is that, if the sysadmin has a large project planned that they could use some additional temporary headcount on, you have someone else with some institutional knowledge lying around.
At least in my experience, RunAs in XP only works tolerably well (i.e. more than 50% of the time) if you RunAs a cmd prompt first, then execute whatever you need to from there. Even then, Windows Explorer won't let you run in a different user context, which basically means that, if you need to move or copy a file, or install a printer, you're either doing it through the command line or not at all. This also often meant that, if you needed to install a program from a CD (looking at you, HP drivers), they'd detect that they were in a "RunAs environment" if you used the GUI RunAs, and then proceed to error out on you. Of course, the workaround for that was to launch an escalated cmd and run whatever program Autorun.inf was configured to call and hope for the best. If you became really good at cmd, you could get around most of that, though I always felt I had other, better things to do with my time than to learn every single option for rundll32 printui.dll,PrintUIEntry, much less netsh.
For the record, I just tried to RunAs appwiz.cpl from my PC and it worked just fine. Of course, the nice thing about Windows 7 is I don't even have to RunAs my Control Panel widgets - if I need administrative access, it will ask for an administrator user name and password when I open it and then escalate for me, saving me from having to remember what options require administrative access and what ones don't. Y'know, like a proper gksudo-type tool should.
Different use cases for different folks, I suppose. Personally, I love being able to hit the Windows key and start typing out the name of whatever utility I need without hitting 'R' first and hoping that "Run..." is the first application on the Start menu that starts with an 'R' today. It really speeds things up, especially if I need something from the Control Panel.
Don't get me wrong, some of Microsoft's "simplifications" leave a lot to be desired - looking at you, Control Panel, at least when you're not in icon mode, and even then, what is up with the Network control panel? - but I'll take Windows 7 and its interface over Windows XP any day of the week.
And I didn't even touch on the actually usable "Run As..." feature - yes, it was there on XP, too, but it only worked half the time. It took Microsoft way too long to add proper sudo-like functionality, but I'm glad they finally did it.
Only in the military, and only under certain circumstances. This is to protect against weaponized smallpox since the US and Russia are the only two countries with labs containing the original virus.
Yes, because if there's one thing that keeps Big Pharma rich, it's selling everyone quick, cheap, effective vaccines instead of expensive, slow-moving treatments to long-term side effects of diseases like measles, polio, and so on.
Want to know what's profitable? Iron lungs. They're expensive and you're hooked on them for, if you're lucky, only a month or two while your body recovers from polio. If you're unlucky, you're hooked on them for life. Know what's less profitable? A single prick in the arm containing a vaccine that, even at the highest markup, costs less than 1/10,000th of a modern day life support system and prevents the disease that lands you in the iron lung in the first place.
Right. That's why I only get my news from reputable sources, like WorldNetDaily, InfoWars, Mother Jones, Russia Times and The Blaze. Oh, and occasionally The Onion, too, because sarcasm is for the sheeple.
Contrary to popular myth, precious metals are not a guarantee of sound money. For starters, governments could - and did - routinely change the peg rate, which precious metals would back the currency, and plenty more. Also, even with a nominally precious metal-based currency, it was quite easy for governments to debase the currency, either by changing the alloy mix (when coinage was in use) or just by overprinting gold certificates (France did this just before the first Revolution; Germany tried this during World War 1). This doesn't even throw capital controls into the mix, or even local inflation, like what happened in California during the '49 Gold Rush.
Pretty much this. There are three ways to handle disagreements:
1. Engage in a respectful, carefully thought out conversation weighing the pros and cons of each position, then achieving some sort of consensus.
2. "Agree to disagree", then passive-aggressively do your own thing or otherwise lobby with others to follow your path over the other person's path.
3. "Be a dick", call the person out, and make it clear that, since you're the one making the decisions, you are the one making that decision, not them.
Option 1 is great when you have nothing but time on your hands and/or when you're dealing with someone whose opinion you trust. It's also only useful when there's a clear definition of "right" and "wrong" regarding the topic at hand - more often than not, choices in life and engineering pretty much boil down to "which trade-offs suck less for the domain we're working in", which are more subjective than not in most cases. Option 2 is the default position drilled into our heads during school, which is a useful default when you're dealing with equals or people who you have no authority over - I mean, sure, you can yell and scream at them, but it's not like they're required to listen. The catch with option 2, though, is that, though it leads to less hurt feelings in the short run, you're as liable to have different factions competing against each other to prove who's "right", which can lead to some major issues down the road.
Option 3, meanwhile, is useful when you're in a hurry, a decision needs to be made now, and it needs to be made decisively. The goal here is to nip a problem in the bud before it metastasizes into something serious and political. In this case, Linus wants to enforce some discipline on the code review process because his time is finite and the deadline is near for 3.10 to get out the door, and "receive lots of crap code and reject it" doesn't solve that problem. He needs to not receive non-essential code in the first place. The only way to do that is by convincing those committing code to make only meaningful commits, either through well-defined requirements (tried; apparently that's failing), polite warnings (what Slashdot picked up here tonight), or "being a dick" (Linus will continue the beatings until morale improves if his warning isn't heeded).
Personally, I've found that the sort of people that claim "being a dick" is the sole refuge of people that enjoy being dicks are the sort of people that have a reflexive inability to defend their opinions under any sort of sustained criticism and just assume that, if their "brilliance" needs to be defended, it's because it's being witnessed by simpletons that just "don't get it". From where I'm sitting, that's a pretty dickish and passive-aggressive position to adopt and I... well, come to think of it, I actually do enjoy being a dick to people that think like that. Seriously, screw them.
Huh. Guess I pretty much proved the grandparent's point right there, didn't I?
Sure you can. Heck, if you have the right version of Windows, you can even eschew the GUI entirely and go straight to the command line. Or, if you're looking for a lightweight DE, you could opt for the Minimal Server Interface.
Granted, it's not quite fvwm, and it's certainly not available on consumer-grade Windows, but it's out there if you really want it and are willing to fork out the money for it.
The SMB space is where cloud adoption is going to spike. Truth is, a lot of smaller shops really have no business hosting their own email, much less some of the other stuff out there (document management servers, etc.). Sure, the "cloud" isn't going to be for everyone - dentists and doctors want their x-rays to show up on their screens now, not when it's done uploading to their EMR and downloaded back to their terminal; forget "data security", THAT'S the big holdup there. But, for smaller construction shops, legal, insurance, and the like? You mean to tell me that they can't convince an auditor (if they ever see one) that their cloud setup is more secure than a server sitting under someone's desk or in an unlocked closet somewhere?
Truth is, most of the changes coming to IT from the "cloud" will have little bearing on larger corporations; they're big enough to hire enough IT people to get the job done right internally, and they have been forever. Where the big change is coming is for your SMB IT consultants and lone wolf "IT Directors" who will suddenly find themselves spending much less time idling in front of Event Viewer and swapping backups, and more time implementing SharePoint portals or looking for career changes. Bear in mind that Microsoft has already told the SMB space to stop self-hosting their own email; Windows SBS (with Exchange) is now officially a thing of the past.
Pretty much this. I'm dual-booting Ubuntu 12.04 and Windows 7 on my cheap Acer (AMD CPU + Radeon Mobile) and the difference in performance is galling. Framerates and CPU loads on Windows 7, at least once I get past boot and the usual start-up virus check, are consistently lower in Windows 7 than Ubuntu for comparable programs. This even holds true for basic software like Firefox and Chrome(-ium, on the Ubuntu side). Much of this, I suspect, has to do with Radeon Mobile's use of "HyperMemory", which Windows seems to actually call from and pull from system RAM, while Linux just keeps the BIOS fixed at 256MB of "VRAM" and puts everything else in CPU-addressable RAM instead.
Granted, Ubuntu has Unity, which is an absolute hog, so that might not be an apples-to-apples comparison; then again it's not like Aero is "low impact". It also doesn't help that a lot of internet-facing applications (Flash, most browsers) are either giving up on Linux entirely (Flash) or are primarily optimized against Windows graphics calls since Linux browser programmers aren't sure whether OpenGL will really be there for them or not, and in what capacity.
Those who are throwing out the "tool for the job" line I think have it about right - Linux was always optimized for server workloads first and everything else second. It makes an excellent server in most circumstances and a poor desktop, almost like a backwards Mac OS X. There's nothing wrong with that - we need good server operating systems. However, there's no shame in admitting that a favored tool isn't the best tool in all circumstances.
To be fair to kids, assembly really isn't the "basics" for their computing world anymore. I guarantee you kids interested in computers these days know more about markup and scripting languages than most greybeards knew about them back in the early '80s, which is as it should be - the only thing most kids in the '80s knew about punch cards, if they knew anything about them, was that they made excellent bookmarks. You also didn't see a lot of kids picking up COBOL, either.
Housing construction: In Europe, current population is either stagnant or shrinking in most countries and the population generally doesn't move around much - it's not entirely uncommon for a family to still be living in the same house their great-great-grandparents moved into during the start of the Industrial Revolution. In America, it's a different story - our population is steadily increasing through a combination of natural birth rates and mild immigration, and our population is arguably one of the most mobile on Earth. Consequently, American housing reflects American needs - it doesn't need to hold up multi-generationally because it won't be in use multi-generationally. It just needs to hold itself together long enough to get the kids into college so the parents can retire into a different, smaller house, preferably one in a warmer climate.
Household appliances: Eh? All the appliances in my apartment are at least a good 15-20 years old and they're holding up okay. Bear in mind here that, if we're going to get serious about energy efficiency, we probably shouldn't be encouraging people to use 50 year old appliances that work "just as well as when they were new".
Cars: You're kidding, right? I've seen European cars. I've owned European cars. There's a reason they're a niche commodity in America - they're expensive and don't hold up nearly as well under American driving conditions as Japanese and (some) American models. Plus, due to the higher concentration of population in Europe, mass transit is used more widely and the road system isn't generally as accommodating as America's - this means that there are a lot of poorer Americans buying cars here that would normally just take a bus or a train in Europe, which means there's a large, paying market of people here that can't afford a C-Class. I'll note that there are several European brands that tried to set up shop here and failed miserably, all with horrific reputations for reliability by the time they were done (anything British, French, and Italian comes to mind, with FIAT doing its best to prove it's learned a thing or two since the last time they were here). Even Volkswagen has a well-deserved reputation for shaky reliability and build quality out here, though I've heard that has as much to do with the price point VW's trying to meet in the US as it does anything else.
Put another way, Americans look at TCO just fine - we're just operating under an entirely different set of parameters than Europeans. Well-built 100-year-old houses are still 100-year-old houses with 100-year-old wiring, 100-year-old plumbing, and 100-year-old room sizes - in our case, we have enough open room and enough money to replace those with newer, better designed houses, and since we know we're just going to replace them again in 25-50 years, we're not going to overbuild them. Similarly, the American definition of a "well built" car is wildly divergent from a European definition - since we practically live in our cars here, we want something that will last 250,000-300,000 miles and/or 10-15 years of constant day-to-day driving first (that's 400,000-500,000 km), we want it to be comfortable to sit in for long periods, and if it can also go around a corner without swaying to-and-fro, so much the better; this, I'll note, is the opposite order of the European definition, which better reflects European needs and conditions. And so on.
Tell that to lawyers that need it to access PACER or their local court filing repository. Or tell that to various medical professionals that have line-of-business apps written in Java (recently stumbled across an pano controller package written entirely in Java - that was cute). Or tell that to certain financial industries that use Java to submit various bits of paperwork (if you're a merchant filing for credit card processing, there's a decent chance your application was scanned and uploaded using a Java app called "AMA", depending on which platform your processor is underwriting with). Or tell that to businesses that electronically deposit checks - quite a few banks out there use scanners with Java software to get the checks from the business' PC into the banking system.
Java's actually fairly commonly used for line-of-business applications because it's fairly easy to find Java developers ("easy" being synonymous with "cheap"), the tools start at "free", it's sort of platform neutral, and it's been around for a while. Plus, a lot of those Java line-of-business apps were first written 5-10 years ago and, well, they still basically work - given a choice between paying for a total re-implementation of some tool that works "reliably", doing the necessary field testing to prove it's at least as secure, functional, and stable as the current implementation, or just periodically testing it against the latest version of Java, guess what most businesses do?
In my experience (and I do do development in environments where this comes up frequently), it is not at all unusual for applications to either rely on buggy behavior of another piece of code, or to make unwarranted assumptions about how another piece of code works, that happens to be valid under some circumstances but not others.
Which is why Linus' policy is that, when the choice is between userland compatibility and better adherence to theoretical documentation of the kernel interface, tie goes to userland compatibility. This is smart - Linux already has enough issues with userland apps breaking backwards compatibility to scratch itches that nobody really has (see GNOME 3, the entire audio stack, etc.); if the kernel is disciplined, at least, it keeps the whole environment from turning into a bug-ridden tar pit.
As for Linus' attitude, well, I have to agree with Linus on this one. Fix the mistake first, either by removing the patch that broke everything or quickly implementing a fix, then ask questions. The first rule of kernel development should always be "Do No Harm". If you're in charge of some part of kernel development and you find yourself breaking that rule, you need to un-break it ASAP, then assess how you found yourself breaking it in the first place. Unfortunately, Mauro wasn't grasping that - he was too busy asking "reasonable questions" to undo the damage that his commit did when his first priority should have been to stabilize the kernel. Don't get me wrong, Mauro's questions are important and they do need to be answered, but only after userland is back to the condition he found it before the commit. And not until then. And *certainly* not with the mainline kernel.
Slashdot Mirror
Cute - apparently Slashdot mobile eats HTML. Fine - Symantec has their HQ location listed here: http://www.symantec.com/about/...
Huh - guess not. I know they have a large office of some sort out there, though - some of their hiring ads bleed over out here. Dentrix support is also based out of SLC (Henry Schein?); used to call out there pretty frequently when I was doing IG support for dental offices.
The University of Utah was one of the original ARPANET nodes back in the '70s, so there's been some tech out there for a while now.
Speaking as a Reno resident (It's Sacramento, only with hookers and blackjack!), I don't like Sacramento's chances, and it's not because I think Reno's chances are any better. Part of the problem is that there won't be a "next Bay Area" - not just one, anyway. The Bay Area's preeminence in the tech industry was kind of a fluke, which resulted from a combination of various factors (strong academic interest from Stanford and Cal, defense industries sprouting up in the area, good weather, and so on). These days, the tech industry is decentralizing, which is why you have "tech corridors" in places like Raleigh-Durham, Austin, Salt Lake City (Symantec is based there), Las Vegas (Zappos), Seattle, Portland (thanks, cheap hydroelectric power!), Los Angeles ("Silicon Beach" - I remember when Venice was a ghetto), Boston... and these are just the places in this country.
The other part of the problem is that Sacramento's biggest claims to fame at this point are that it's the state capital of California (*shrug*) and it's kind of close to the Bay Area (so is Vallejo, Vacaville and Antioch). The climate is miserable (think Texas weather, only with a little less humidity, no hurricanes and without the weird bugs), the neighborhoods are extremely hit-and-miss, the culture is getting better but is still more or less non-existent, California's tax and business codes are pretty obnoxious, the physical infrastructure in Sacramento isn't quite Stockton bad but there's definitely room for improvement... yeah. Sacramento's not bad, but it's not good, either.
Don't get me wrong, I think Sacramento will get some startups to set up shop there. Some of them will probably succeed. I don't think they're going to take over the world out there, though. Venture capitalists would rather go to Denver, Seattle, Portland or Las Vegas than Sacramento, and if you're going by plane, you're not saving that much time by going to Sacramento over either of those other places.
This is actually a good thing for PC-BSD for a variety of reasons. First, KDE's support for BSD is spotty - try mounting NTFS volumes using Dolphin in PC-BSD. You can't because KDE uses Linux-style mount options instead of BSD's. Also, KDE is (L)GPL, which BSD has been trying to avoid lately (hence Clang, LLVM, etc.).
I'm concerned that iXsystems and the community is biting off a bit more than they can chew - Canonical's having issues getting Unity out the door and, though I don't have either of their financials in front of me, my assumption would be that Canonical is a much bigger company with a much bigger community of developers behind them. However, if PC-BSD is going to get the stability and ease of use that's necessary to be a compelling desktop alternative for all but a few hobby enthusiasts, they're either going to have to maintain a BSD-friendly port of KDE or roll their own desktop manager.
There's also the issue of the existing infrastructure, versus how many people are out on the playa. Figure attendance is roughly 50,000 people or so, with an average of two people per vehicle. That's up to 25,000 vehicles leaving at a BLM-mandated 1,000/hour - a mandate, by the way, created to ensure that the two-lane road from Gerlach to I-80 still has some room to let the natives, both in Gerlach and "downstream" in Pyramid Lake", actually get out of their driveways and go somewhere that day. Do the math and some people are going to wait for a long, long, long time.
For those of you from Europe or those just generally not from the area, here's what's basically happening:
There is only one paved road to the Black Rock Desert - Nevada State Route 447 - which is only useful for most people if you take it heading southbound since that's the fastest way to an interstate (that's American for "large freeway") and is also the only direct route to Reno (nearest major airport) and the Bay Area. The total population served by this road is maybe 1,000 (I'm feeling generous), so the road is built accordingly - it's a two-lane highway that's generally straight thanks to the local geography but makes a rather firm point to go right through the middle of what habitation there is in the area (notably, Nixon and Wadsworth). The few towns served by the highway are consequently bisected by it - thus, if the highway gets overwhelmed, it's impossible for residents of the town to cross the street. Also, adding insult to injury, there's not a tremendous amount of freeway or onramp capacity once the highway reaches the freeway (no cloverleaf or anything), so excessive oncoming traffic can cause localized traffic issues on the freeway, too.
In short, Burning Man needs to somehow evacuate over 50,000 people using infrastructure built for less than 1,000 within 24 hours, and do in a way that doesn't paralyze the lives of every single town in the area. No matter how you look at that problem, people are going to have to wait - the only question is whether people are waiting with their keys in the ignition, whether they're waiting for their license plate number to come up, or some other means of queue management. It's either that or try to convince everyone to drive through Cedarville and Alturas to go home, not that they're equipped to deal with any significant traffic themselves.
RDP? SSH tunnels? Blasphemy. If you're using an SSH tunnel, all you need to do after that is enable WinRM, hit the remote cmd console, download a VNC server using BITSADMIN, and then go from there. Bonus points if you somehow manage to rope PowerShell connection and session objects into the mix.
Seriously though, TeamViewer is fine. The point of LogMeIn was that, if you needed remote access to another user's PC but they weren't technically savvy, you could walk them through it without too much trouble. SSH tunnels and proper VPNs are certainly preferable if you're in charge of both ends of the connection, but if you're not, TeamViewer, Jump Desktop, and the like get the job done without too much fuss.
Assuming the schema matches. Which, by the way, is an extremely bold assumption when you're dealing with pulling data out of a custom Access solution cobbled together over the past decade and pushing it into an out-of-the-box solution.
Having seen a few custom Access jobs in my time, I can tell you first-hand that, more often than not, you're lucky if the data is normalized, much less organized in any sane, sensible way. I've seen tables where there are "Serial Number 1", "Serial Number 2", and "Serial Number 3" fields, for example, because "nobody has more than three pieces of equipment". So, now you're faced with having to get that data halfway normalized, or at least document how you could normalize it, and then you have to map it up against the new solution's schema and hope and pray they have a set of tables that are designed to hold the data you're looking for.
You wouldn't - but you'd really prefer to not use NetBIOS names under any circumstances. Otherwise, SERVER1 is always going to have to resolve somewhere, regardless of domain, regardless of network topology, and that somewhere better be where the database expects to find useful data.
Having worked for a smaller company that could only afford a one person IT department, I agree that it doesn't make sense paying for a second full time person to sit around and stare at the primary sysadmin while they do their job. Frankly, in most companies with one person IT departments, work load is somewhat inconsistent to begin with - oftentimes there's just enough work to do where it would cost more to bring in a part-time consultant to do 4 hours of work that day than to pay the full time sysadmin to do 4 hours of work and then read Slashdot for the other 4. That problem would only get worse if you had to pay for an "understudy".
Thankfully, there's a really easy way to manage that, even for smaller companies. Bring in a part-time consultant periodically (say, for a couple hours every month) as an insurance policy. For the brief period they're there, have them focus on documentation and chatting up the sysadmin. As an added bonus, maybe have them check backups, server logs and the like to ensure the sysadmin isn't falling asleep at their desk. Another bonus is that, if the sysadmin has a large project planned that they could use some additional temporary headcount on, you have someone else with some institutional knowledge lying around.
At least in my experience, RunAs in XP only works tolerably well (i.e. more than 50% of the time) if you RunAs a cmd prompt first, then execute whatever you need to from there. Even then, Windows Explorer won't let you run in a different user context, which basically means that, if you need to move or copy a file, or install a printer, you're either doing it through the command line or not at all. This also often meant that, if you needed to install a program from a CD (looking at you, HP drivers), they'd detect that they were in a "RunAs environment" if you used the GUI RunAs, and then proceed to error out on you. Of course, the workaround for that was to launch an escalated cmd and run whatever program Autorun.inf was configured to call and hope for the best. If you became really good at cmd, you could get around most of that, though I always felt I had other, better things to do with my time than to learn every single option for rundll32 printui.dll,PrintUIEntry, much less netsh.
For the record, I just tried to RunAs appwiz.cpl from my PC and it worked just fine. Of course, the nice thing about Windows 7 is I don't even have to RunAs my Control Panel widgets - if I need administrative access, it will ask for an administrator user name and password when I open it and then escalate for me, saving me from having to remember what options require administrative access and what ones don't. Y'know, like a proper gksudo-type tool should.
I won't miss XP, is what I'm saying.
Different use cases for different folks, I suppose. Personally, I love being able to hit the Windows key and start typing out the name of whatever utility I need without hitting 'R' first and hoping that "Run..." is the first application on the Start menu that starts with an 'R' today. It really speeds things up, especially if I need something from the Control Panel. Don't get me wrong, some of Microsoft's "simplifications" leave a lot to be desired - looking at you, Control Panel, at least when you're not in icon mode, and even then, what is up with the Network control panel? - but I'll take Windows 7 and its interface over Windows XP any day of the week. And I didn't even touch on the actually usable "Run As..." feature - yes, it was there on XP, too, but it only worked half the time. It took Microsoft way too long to add proper sudo-like functionality, but I'm glad they finally did it.
No, but Shingles is. Vaccinate against Chicken Pox (which is usually fairly mild) and you get a two-for-one deal out of it.
Only in the military, and only under certain circumstances. This is to protect against weaponized smallpox since the US and Russia are the only two countries with labs containing the original virus.
Yes, because if there's one thing that keeps Big Pharma rich, it's selling everyone quick, cheap, effective vaccines instead of expensive, slow-moving treatments to long-term side effects of diseases like measles, polio, and so on.
Want to know what's profitable? Iron lungs. They're expensive and you're hooked on them for, if you're lucky, only a month or two while your body recovers from polio. If you're unlucky, you're hooked on them for life. Know what's less profitable? A single prick in the arm containing a vaccine that, even at the highest markup, costs less than 1/10,000th of a modern day life support system and prevents the disease that lands you in the iron lung in the first place.
Critical thinking - how does it work?!
Right. That's why I only get my news from reputable sources, like WorldNetDaily, InfoWars, Mother Jones, Russia Times and The Blaze. Oh, and occasionally The Onion, too, because sarcasm is for the sheeple.
Contrary to popular myth, precious metals are not a guarantee of sound money. For starters, governments could - and did - routinely change the peg rate, which precious metals would back the currency, and plenty more. Also, even with a nominally precious metal-based currency, it was quite easy for governments to debase the currency, either by changing the alloy mix (when coinage was in use) or just by overprinting gold certificates (France did this just before the first Revolution; Germany tried this during World War 1). This doesn't even throw capital controls into the mix, or even local inflation, like what happened in California during the '49 Gold Rush.
Pretty much this. There are three ways to handle disagreements:
1. Engage in a respectful, carefully thought out conversation weighing the pros and cons of each position, then achieving some sort of consensus.
2. "Agree to disagree", then passive-aggressively do your own thing or otherwise lobby with others to follow your path over the other person's path.
3. "Be a dick", call the person out, and make it clear that, since you're the one making the decisions, you are the one making that decision, not them.
Option 1 is great when you have nothing but time on your hands and/or when you're dealing with someone whose opinion you trust. It's also only useful when there's a clear definition of "right" and "wrong" regarding the topic at hand - more often than not, choices in life and engineering pretty much boil down to "which trade-offs suck less for the domain we're working in", which are more subjective than not in most cases. Option 2 is the default position drilled into our heads during school, which is a useful default when you're dealing with equals or people who you have no authority over - I mean, sure, you can yell and scream at them, but it's not like they're required to listen. The catch with option 2, though, is that, though it leads to less hurt feelings in the short run, you're as liable to have different factions competing against each other to prove who's "right", which can lead to some major issues down the road.
Option 3, meanwhile, is useful when you're in a hurry, a decision needs to be made now, and it needs to be made decisively. The goal here is to nip a problem in the bud before it metastasizes into something serious and political. In this case, Linus wants to enforce some discipline on the code review process because his time is finite and the deadline is near for 3.10 to get out the door, and "receive lots of crap code and reject it" doesn't solve that problem. He needs to not receive non-essential code in the first place. The only way to do that is by convincing those committing code to make only meaningful commits, either through well-defined requirements (tried; apparently that's failing), polite warnings (what Slashdot picked up here tonight), or "being a dick" (Linus will continue the beatings until morale improves if his warning isn't heeded).
Personally, I've found that the sort of people that claim "being a dick" is the sole refuge of people that enjoy being dicks are the sort of people that have a reflexive inability to defend their opinions under any sort of sustained criticism and just assume that, if their "brilliance" needs to be defended, it's because it's being witnessed by simpletons that just "don't get it". From where I'm sitting, that's a pretty dickish and passive-aggressive position to adopt and I... well, come to think of it, I actually do enjoy being a dick to people that think like that. Seriously, screw them.
Huh. Guess I pretty much proved the grandparent's point right there, didn't I?
Sure you can. Heck, if you have the right version of Windows, you can even eschew the GUI entirely and go straight to the command line. Or, if you're looking for a lightweight DE, you could opt for the Minimal Server Interface.
Granted, it's not quite fvwm, and it's certainly not available on consumer-grade Windows, but it's out there if you really want it and are willing to fork out the money for it.
The SMB space is where cloud adoption is going to spike. Truth is, a lot of smaller shops really have no business hosting their own email, much less some of the other stuff out there (document management servers, etc.). Sure, the "cloud" isn't going to be for everyone - dentists and doctors want their x-rays to show up on their screens now, not when it's done uploading to their EMR and downloaded back to their terminal; forget "data security", THAT'S the big holdup there. But, for smaller construction shops, legal, insurance, and the like? You mean to tell me that they can't convince an auditor (if they ever see one) that their cloud setup is more secure than a server sitting under someone's desk or in an unlocked closet somewhere? Truth is, most of the changes coming to IT from the "cloud" will have little bearing on larger corporations; they're big enough to hire enough IT people to get the job done right internally, and they have been forever. Where the big change is coming is for your SMB IT consultants and lone wolf "IT Directors" who will suddenly find themselves spending much less time idling in front of Event Viewer and swapping backups, and more time implementing SharePoint portals or looking for career changes. Bear in mind that Microsoft has already told the SMB space to stop self-hosting their own email; Windows SBS (with Exchange) is now officially a thing of the past.
Pretty much this. I'm dual-booting Ubuntu 12.04 and Windows 7 on my cheap Acer (AMD CPU + Radeon Mobile) and the difference in performance is galling. Framerates and CPU loads on Windows 7, at least once I get past boot and the usual start-up virus check, are consistently lower in Windows 7 than Ubuntu for comparable programs. This even holds true for basic software like Firefox and Chrome(-ium, on the Ubuntu side). Much of this, I suspect, has to do with Radeon Mobile's use of "HyperMemory", which Windows seems to actually call from and pull from system RAM, while Linux just keeps the BIOS fixed at 256MB of "VRAM" and puts everything else in CPU-addressable RAM instead.
Granted, Ubuntu has Unity, which is an absolute hog, so that might not be an apples-to-apples comparison; then again it's not like Aero is "low impact". It also doesn't help that a lot of internet-facing applications (Flash, most browsers) are either giving up on Linux entirely (Flash) or are primarily optimized against Windows graphics calls since Linux browser programmers aren't sure whether OpenGL will really be there for them or not, and in what capacity.
Those who are throwing out the "tool for the job" line I think have it about right - Linux was always optimized for server workloads first and everything else second. It makes an excellent server in most circumstances and a poor desktop, almost like a backwards Mac OS X. There's nothing wrong with that - we need good server operating systems. However, there's no shame in admitting that a favored tool isn't the best tool in all circumstances.
To be fair to kids, assembly really isn't the "basics" for their computing world anymore. I guarantee you kids interested in computers these days know more about markup and scripting languages than most greybeards knew about them back in the early '80s, which is as it should be - the only thing most kids in the '80s knew about punch cards, if they knew anything about them, was that they made excellent bookmarks. You also didn't see a lot of kids picking up COBOL, either.
Let's go through the list...
Housing construction: In Europe, current population is either stagnant or shrinking in most countries and the population generally doesn't move around much - it's not entirely uncommon for a family to still be living in the same house their great-great-grandparents moved into during the start of the Industrial Revolution. In America, it's a different story - our population is steadily increasing through a combination of natural birth rates and mild immigration, and our population is arguably one of the most mobile on Earth. Consequently, American housing reflects American needs - it doesn't need to hold up multi-generationally because it won't be in use multi-generationally. It just needs to hold itself together long enough to get the kids into college so the parents can retire into a different, smaller house, preferably one in a warmer climate.
Household appliances: Eh? All the appliances in my apartment are at least a good 15-20 years old and they're holding up okay. Bear in mind here that, if we're going to get serious about energy efficiency, we probably shouldn't be encouraging people to use 50 year old appliances that work "just as well as when they were new".
Cars: You're kidding, right? I've seen European cars. I've owned European cars. There's a reason they're a niche commodity in America - they're expensive and don't hold up nearly as well under American driving conditions as Japanese and (some) American models. Plus, due to the higher concentration of population in Europe, mass transit is used more widely and the road system isn't generally as accommodating as America's - this means that there are a lot of poorer Americans buying cars here that would normally just take a bus or a train in Europe, which means there's a large, paying market of people here that can't afford a C-Class. I'll note that there are several European brands that tried to set up shop here and failed miserably, all with horrific reputations for reliability by the time they were done (anything British, French, and Italian comes to mind, with FIAT doing its best to prove it's learned a thing or two since the last time they were here). Even Volkswagen has a well-deserved reputation for shaky reliability and build quality out here, though I've heard that has as much to do with the price point VW's trying to meet in the US as it does anything else.
Put another way, Americans look at TCO just fine - we're just operating under an entirely different set of parameters than Europeans. Well-built 100-year-old houses are still 100-year-old houses with 100-year-old wiring, 100-year-old plumbing, and 100-year-old room sizes - in our case, we have enough open room and enough money to replace those with newer, better designed houses, and since we know we're just going to replace them again in 25-50 years, we're not going to overbuild them. Similarly, the American definition of a "well built" car is wildly divergent from a European definition - since we practically live in our cars here, we want something that will last 250,000-300,000 miles and/or 10-15 years of constant day-to-day driving first (that's 400,000-500,000 km), we want it to be comfortable to sit in for long periods, and if it can also go around a corner without swaying to-and-fro, so much the better; this, I'll note, is the opposite order of the European definition, which better reflects European needs and conditions. And so on.
Tell that to lawyers that need it to access PACER or their local court filing repository. Or tell that to various medical professionals that have line-of-business apps written in Java (recently stumbled across an pano controller package written entirely in Java - that was cute). Or tell that to certain financial industries that use Java to submit various bits of paperwork (if you're a merchant filing for credit card processing, there's a decent chance your application was scanned and uploaded using a Java app called "AMA", depending on which platform your processor is underwriting with). Or tell that to businesses that electronically deposit checks - quite a few banks out there use scanners with Java software to get the checks from the business' PC into the banking system.
Java's actually fairly commonly used for line-of-business applications because it's fairly easy to find Java developers ("easy" being synonymous with "cheap"), the tools start at "free", it's sort of platform neutral, and it's been around for a while. Plus, a lot of those Java line-of-business apps were first written 5-10 years ago and, well, they still basically work - given a choice between paying for a total re-implementation of some tool that works "reliably", doing the necessary field testing to prove it's at least as secure, functional, and stable as the current implementation, or just periodically testing it against the latest version of Java, guess what most businesses do?
Now you know why Java exploits are a big deal.
Yes, but they had abortions in the 19th century, too.
Which is why Linus' policy is that, when the choice is between userland compatibility and better adherence to theoretical documentation of the kernel interface, tie goes to userland compatibility. This is smart - Linux already has enough issues with userland apps breaking backwards compatibility to scratch itches that nobody really has (see GNOME 3, the entire audio stack, etc.); if the kernel is disciplined, at least, it keeps the whole environment from turning into a bug-ridden tar pit.
As for Linus' attitude, well, I have to agree with Linus on this one. Fix the mistake first, either by removing the patch that broke everything or quickly implementing a fix, then ask questions. The first rule of kernel development should always be "Do No Harm". If you're in charge of some part of kernel development and you find yourself breaking that rule, you need to un-break it ASAP, then assess how you found yourself breaking it in the first place. Unfortunately, Mauro wasn't grasping that - he was too busy asking "reasonable questions" to undo the damage that his commit did when his first priority should have been to stabilize the kernel. Don't get me wrong, Mauro's questions are important and they do need to be answered, but only after userland is back to the condition he found it before the commit. And not until then. And *certainly* not with the mainline kernel.