I would have to agree with this stance whole heartedly. I wrote a little bastard love child utility for Windows C++ coders, and the code itself is written in.NET because I was feeling especially lazy that day. I've since had a few people download it, most say they liked it, and only one person mentioned that I could probably make it run faster if I used a DLL from the Wine project instead of invoking the Visual Studio tools and parsing their results.
The main point being, this was a "throw away" application that I wrote one day in about an hour. I made a few bug fixes here and there, and then I've since left it to rot up on SF.net. I still occasionally use it, and apparently some other people do too. I only uploaded it because I felt that if I had a need for this, someone else out there might need it as well. Apparently I was right.
I missed this post by a few hours, so this reply will be undoubtedly buried, but I'll post my $0.02 anyhow.
The problem with Linux on the desktop is not the lack of the "killer app", as so many people are trying desperately to solve. It isn't even the GUI interface selection, or any of the other standard responses as to why Linux is flailing without much penetration into the desktop world. The #1 reason why Linux doesn't have a bigger installation base is because it has yet to penetrate the business desktop market, and that fault can be summed up into one service: Native Enterprise Authentication (ie. Active Directory for Linux).
When Windows pushed out the mainframes of its day, computing was still in its infancy, and security/privacy laws hadn't yet adapted to the computing age. Active Directory came along much later in their lineup simply because it wasn't necessary at the time. Once MS saw that site-wide authentication with integrated single sign-on was the only route left to go, they hit the nail on the head with the biggest damn hammer available. They coupled LDAP with Kerberos into a single service that provided a company directory, user authentication, and single sign-on capabilities. Later their killer app became Exchange, and Exchange could never work the way it does without Active Directory. These days we have several Linux installations that are authenticating against Active Directory, as that is the currently installed authentication system within the enterprise. Hell, there are even companies that exist solely around the concept of making this setup work as easily and flawlessly as possible.
If you want Linux to really penetrate the Enterprise desktop market (which in turn has been historically proven to increase home desktop penetration), then what Linux really needs is its own native version of Active Directory. Even if we just cloned the service it would at least make Linux/Windows integration much cleaner, but ideally it would be more than that. Either way, it would need to at least provide the same data as Active Directory, as adding a method of authenticating Windows machines against it would be necessary. This could start as simply a mash-up of Kerberos and LDAP with a management front end, but the end goal should be a stand alone service that is easy to install and easy to maintain.
There. My $0.02. Don't spend it all in once place.
Seriously though, why would ANYONE consider it smart to get out of jury duty when the decisions of the juries impacts case law like no other. Why is "Getting out of jury duty" considered smart? Yes, it is a hassle and there are opportunity costs involved, but think of the cost of ALL JURIES BEING RETARDED.
Because they don't actually tell you what the case is about until you hear the opening statements?
Seriously. There are plenty of time wasting jury trials out there, and out of the whole lot of them I'd wager that only somewhere around 1% are actually worth being a part of for the sake of keeping technology unfucked.
Juries haven't been panels of peers in the computer business because they use juries built from the common populace, and that means that technologically savvy people are still a vast minority within them. If they wanted to make law a little more useful, they'd use demographically driven jury selection for cases involving specialty areas like technology.
Oh well, we'll just keep digging this hole. After all, it's "worked" thus far...
System Administrators Handbook:
* Rule #1: Never give sudo access to anyone that you would not trust to have root access. The sudo tool is merely a mechanism to provide a short barrier between the user and complete access where they could otherwise ruin the system with one mistaken command. A determined user will almost always find a way to gain a root shell if given sudo privileges.
I used to be surprised by the number of people that assumed sudo prevented other users from having root access while still being able to perform commands. These days I just chalk it up as the most misused privilege escalation technique.
You want to know what sudo is REALLY good for? It's great for giving out full root privileges without having to give out the root password. Just one less password for them to remember, that's about it. Any other reason for sudo usage is better served by a restricted setuid shell/application.
Actually, you're both right and wrong at the same time. Yes the cable company can divide up the spectrum as they see fit, but it isn't as dynamic of a change as you imply. The modem downloads a config file which dictates to it the channels it is supposed to use for this boot, and it cannot be changed without rebooting the modem. This config file also contains SLA enforcement info, like how fast it is allowed to upload, how many local MAC addresses are allowed on the LAN side, etc. Now these channels are fixed in spectrum size. Only so much data can be crammed down a channel. If you want to send more, you need to allocate a new channel. Now comes the fun, as every channel with upstream data must be rejoined with the pre-existing stream on it's way back to the head-end (remember, this is a tree network). This is a classic example of a denial of service waiting to happen. Fill one side completely (after all, it looks clear from this side branch in the tree), and the other branch has no room to insert its own data. Of course, the other branch is guaranteed its fair share, so the node will simply forcefully insert its own data by dropping someone else's data if the need arises. Scale that up on both sides and I bet you can guess what will happen... Adding more channels requires rebuilding every affected node, which requires guys in a trucks to drive out there and perform the work, which can easily cost hundreds of thousands of dollars to perform if the change required is deep into the network.
Now keep in mind that these guys still view internet as a secondary technology to television, and you'll find that the spectrum left over for high speed data is actually fairly small in comparison. There isn't as much head room available in these systems as people like to believe. Yes, it's a closed system, so you have the entire spectrum available, but useful data can only realistically fit within a small subset of the full spectrum. Anything lower in frequency is unusably slow/not enough ROI to make it worth while, and anything higher is incomprehensible from noise.
Cable systems are very different from the other media layers people are so often familiar with, which always makes explaining these issues such a task. Either way, I stated my piece and have explained the reasoning multiple times from many different angles. I leave the rest as an exercise for the reader. =)
Ah yes, the market differences. I believe you are right in that my US centric thinking (after all, I am American and I might as well live up to the stereotype) has cast a US specific scenario upon the whole situation. In the US, ISPs mostly just lease the pipe at whatever capacity they need, and the cost is flat whether they fill it 100% of the time or keep it mostly idle. There are obviously a whole slew of variables that can be applied that will adjust pricing (such as if the line is supposed to be a fail over path only, which reduces cost because the supplier can assume the line will remain mostly dormant). And of course, you can probably strike a deal for cheaper bandwidth at the tier 1/2 level by agreeing to some rule that your network throughput will look mostly like the infamous 10:1 ratio, which they'll just use to their advantage by using up the leftover:9 by suppling hosting or colocation services to others.
The main point wasn't really supposed to be about how ISPs lease their bandwidth, but rather about the radically different approach to infrastructure design that cable systems employ when compared to DSL. In the end, that's all that really matters, as it's the only constant factor in the equation. Both the DSL and cable suppliers can choose to lock themselves in to SLAs that only provide 10:1 bandwidth models, but the main factor is that the last mile in a cable system doesn't scale well for P2P, as compared to DSL (where P2P traffic truly is effectively "free").
You're comparing apples to apples and swearing to god that one of them is an orange. First off, any ISP that pays per packet is doomed to fail just out of lack of business ability. They really do get much better deals on the bandwidth than that. What they pay for is whatever is negotiated.
Generally that ends up being: Line leasing costs for line of size X + network connection costs of $X per quarter to have that line connected at a certain transfer rate and guaranteed a minimum speed at any point in time. In other words, the connection is massive, paid for in bulk, and is assigned a certain data rate and given a Quality Of Service level that is guaranteed in writing the Service Level Agreement.
Any company that charges its end users per MB or kB for traffic in either direction is only doing so because of a few possible reasons. Most notably: A) they are severely overselling their capabilities in order to keep the price low, and need to keep a tight leash on users to maintain the illusion of a decent infrastructure; or B) they are way too greedy and managed to convince their end users that this billing model is "OK".
So once again, no, ISPs don't pay per packet, the lease a physical wire from some entity, and pay someone (often that same entity, but not always) to plug the other end into an edge router that is in some way, shape, or form, eventually hooked up to the internet. The amount they pay to this higher tier ISP will determine the amount of throttling that takes place on that line.
All of this means that any traffic that leaves (or enters) their network through that leased line incurs no additional cost by itself. It isn't like they pay $0.02 cents per packet. The line is paid for in full regardless of whether it is kept at 5% capacity or 100% capacity. The extra outbound packet does nothing at this point but raise the water level just a little bit more. Eventually, when combined with all the other packets from their other customers, it will saturate the line, and thus require they either change their policies or beat down their users for hogging too much bandwidth, but again, the packet itself has no additional cost.
And this is just like... you guessed it: keeping the packet on the internal network. At this level, the company is leasing a line to YOU, and that line is (supposedly) going to provide you with unbelievable speed at an unbelievable discount. And it's all unbelievable because (like all things that are too good to be true) it really isn't true. The connection at their head-end, and often (especially in cable systems) the line itself is severely oversold. But in the end, this works out. Most people check their email, read cnn.com for 30 minutes, and go to watch TV for the rest of the night. This is the conventional traffic demographic. They oversell the lines because statistically, no one is going to hog their entire share for any great length of time. The lines themselves are an investment of the owning company, and they pay for them regularly by maintaining them with their own crews. (See? Apples to apples, not apples to oranges. Both connections are paid for as a bulk commodity, not as an itemized list of packets that pass through them.)
This is what bring us back to my original statement. In a DSL system, the line that YOU lease is physically separate from the other subscribers up until it reaches the head-end. Your last mile is guaranteed available just to you. You can cram that line full of traffic to your heart's content, and as long as the traffic you generate never really leaves the head-end out the Internet on-ramp line, no one is going to care. (Unless they are overselling the capabilities of their DSLAM, but that's a different limitation entirely.) However, in CABLE systems, there is no such thing as a dedicated line. The last mile is shared amongst all subscribers. When you cram your share full of traffic, you affect your neighbor and the neighborhood across the street, and even the people across town. As your packets travel toward the head-end,
Seriously, do these "researchers" even HAVE cable internet? Upstream is only user segregated to the head-end for bare copper technologies like DSL. Cable broadband is built on a tree network. Sure, you can build more nodes into the infrastructure to free up a bit more upstream within a single neighborhood, but eventually that upstream has to be combined with the upstream from all the other nodes. Eventually you just can't squeeze any more data into the upstream band and everything stalls. This is one of the reasons why you don't see SDSL equivalents in cable systems. They always give you more downstream than upstream because downstream is cheap for them. Massive upstream requires a lot more infrastructure investment, which heavily cuts into their profit margins. And yes, the data has to go all the way back to the head-end before it can be resent to an IP in the same cable system, even if they are on the same node.
P2P just isn't useful for cable systems. They're better served by caching technologies like transparent proxy servers.
Yes, it can go through the clipboard, and it often does as that's the easiest way to paste text into a random text box. However, there are other methods of moving data that do not require the use of the clipboard. For instance, Win32API provides applications with the ability to pass messages directly to other windows. Since every control is a window (more or less), you can actually inject the keydown/keyup messages directly into the desired control without ever touching the OS's keyboard hooks or the clipboard. All you need is the target HWND, which the user could easily supply through some global hotkey that triggers a focus probe.
Still, even that doesn't really solve the problem. All I did there was move it. The OS could still be hooked for all messages. In the end, nothing you do can make an unknown terminal secure. If you didn't bring your own laptop, known to be secure, and use network encryption with preshared keys, you're just asking to be spied upon. It's just a matter of how much effort the eavesdropper wants to expend to get your data.
5.) GPL Solaris and remove the distinction between Solaris and OpenSolaris.
and
Solaris has the prime advantage of not having an image torn to tiny bits and pieces by a thousand distributions
These two concepts are mutually exclusive. GPL'ing Solaris will undoubtedly create a thousand distributions. I believe the biggest problem people have in understanding the situation is that Solaris is an OS, not just a kernel (like Linux). Sun doesn't have to beat Linux as a whole to complete their stated objective. They just need to surpass the top Linux distribution (probably Ubuntu or RedHat).
The rest of your post is a mixed bag as well.
There are quite a few useful CLI tools that have no GNU replacement. For example: dtrace is insanely useful, and I challenge you to show me some level of equivalence from the GNU tools. The only CLI tools I can see as good candidates for replacement are the non-OS specifics. Things like grep, sed, awk, less, more, etc.
zshell as the default shell, I'll bite. Why not. If I hate it, I can always run back to tcsh.
I also see no reason to join Solaris and OpenSolaris at the hip under a single name. It is more advantageous for them to remain separate entities so that companies know that moving to OpenSolaris means that their custom scripts and etc will not necessarily work exactly as written for their previous Solaris environment. Give them another Solaris version, 10 years of support, and then start to kill it off. OpenSolaris should be the new direction, but there needs to be a distinct line that identifies them as separate operating systems.
APT as a distribution system: that or YUM, I don't care. Just oh please god, for fuck's sake, kill off pkgadd. That thing is about 10 miles away from being anything more than a nightmare designed to give the sys admins bulletproof job security. The one and only bitch that I will continue to maintain about Unix style package systems is the idea that software is managed by the same database as the OS patches. I shouldn't need to dig through 900 pkgs/RPMs/debs/whatever just to uninstall Open Office. Use the same package system if you must, but please start doing a better job of application separation. The OS needs to come with a finite set of tools, and after that all additional dependencies just plain need to be packaged with the application that requires them, and nicely installed into a separate directory tree (*cough*/opt). Use symlinks if you want to make some CLI stuff available to the users, and GUI apps just plain don't need it. (Hey wait, that sounds like a Mac! (no shit...))
Unifing GTK and QT with the same, one and only default theme that looks good: not a priority. I have a better solution. Pick one. Yes, pick one. QT or GTK, not both. Why? Because the separate GUI camps are doing just as much damage as they are helping. Sure, we end up with all sorts of nifty advances in GUI methodology, but at the end of the day, they never look the same even when the themes are designed to match, and they all try to fix duplicate problems by providing their own sounds systems, clipboards, etc, which seem to never want to work together correctly. (In my opinion, Qt should have been a system stacked on to of GTK, but too late now.) Just pick one and use it exclusively. ISV developers enjoy some level of scarceness in options, especially when it comes to something that should be as elementary as which GUI library their app is supposed to be written upon.
Marketing army: One word. YES! If they manage to take the x86 Unix as a desktop concept and unfuck it, you bet your ass they should jump up and down and throw chairs and all sorts of Ballmerisms. I believe they would have earned the right to be excited about something as monumental as that. Mac did a great job at their endeavor, but they control all the hardware, so it wasn't much different than making the current Solaris look p
Not to nitpick this exact post, as I'm seeing this all over, but...
Well frankly, I don't see the issue with BLOB drivers. If a BLOB driver can crash your system, that isn't entirely the shitty driver developer's fault. Sure, they wrote the crap code that doesn't work, but the OS (and to some degree, the bus design) is at fault for giving up that much control to the driver in the first place. There are very few drivers that truly require full control of the entire system in order to work. A good system design coupled with a good OS can gracefully segregate all software and hardware failures until the very last straw (at which point your system is so fucked that nothing useful remains anyhow, so who cares).
If your video card driver fails, just dump the driver blob, reset the hardware slot, and reload the driver. If the underlying software isn't capable of recovering from a hardware failure of that magnitude, we'll say X.org, then I guess X.org is going to crash. Good thing that's not much unlike hitting Ctrl-Alt-Backspace, and gdm will just restart it. If the device continues to fail, the OS simply flags the device error and turns it off until a sys admin deals with it.
The same can be done for hard-drive controllers, sound cards, web-cams, network cards, etc. Kill the driver, reset the device (look! a known device state!) and reload the driver. This isn't a new concept. Plenty of big iron already does this sort of "magic" (and has for years), and it works surprisingly well. The reason that it doesn't work for Linux is because most people assume Linux == an x86 clone, which doesn't provide a system bus capable of this sort of individual device reset, and probably never will simply because the primary market segment doesn't need (or even know about) this level of system stability.
Consequently, this bus model is the same one that provides hot swap on "integral" hardware devices. Yes, it does exist, and it can hot swap memory, CPUs, video cards, network devices, etc. And although you do reap the consequences of these swaps (ripping out a stick of RAM is generally going to cause some app to crash), however if you let the OS know what you are going to do before you actually do it you'd be surprised with what you can get away with without having to touch the power button.
If you want someone to bitch at for making your PC unstable, don't look at the driver vendor or the OS (at least not yet). The driver vendor just wrote a driver that (supposedly) works for the given platform, and the OS is (supposedly) just doing everything that it can to make a stable system out of what is available. If you want somewhere to point the finger, point it at the architecture designers *cough* Intel/AMD *cough*. They're the ones that dictate how free you will ever be from misbehaving devices/drivers bringing down your whole system. Until x86 receives a hot-pluggable bus, there's really only so much that can be done.
Even the best fully open source driver in existence will bring down an entire system if a piece of hardware fails. That's the way the architecture is designed. Sorry to burst the bubble of the flamers. *shrug*
In terms of equations you are not supposed to remember it (mostly). You are supposed to understand it.
Tell that to my high school trigonometry teacher. (Those were the days...) He expected everyone to remember every trig equation like they came up with it themselves. (And I mean ALL of them, not just the simple stuff.)
So when I found out that he was allowing students to use graphing calculators on the final exam since, "they won't help you anyways", I spent the last week of class time slowly entering all of the functions into my TI-85 so I could refer to them later. Turns out what I did was "damn smart (tm)", because he used every single last one of them on the exam multiple times.
That was the last time I used most of those equations. I still use a few here and there, but never frequently enough to really remember anything past the basic use cases of sin/cos and what their output looks like. In the end I feel that I have accomplished the requirements of high school level trig, as I understand how and why trig works, but asking people to remember those equations is unrealistic and it made the class artificially difficult.
I think the point was supposed to be something about how the libraries commonly used already do support multiple compile targets (usually including Linux), but the licensing costs outweigh the expected ROI due to the market demographics for Linux users.
I never read TFA, so I was expecting -1: Off-topic, but with karma to burn, who cares? =)
As for the DX layer I was referencing, I was talking about Immediate mode, not Retained. From my experience, Immediate mode requires far more operations to achieve the same result as compared to OpenGL. Not that any of it really matters, as neither system is very easily used when inlined directly into the game code. You'd end up writing the same 10 lines of code 50+ times all over the place, when in reality that should just been made into a function call.
I used to do network/systems support for local area businesses, many of them being insurance agencies. When I heard that one of my biggest clients was moving from a local installation of their primary software package to software as a service, I was a very happy man. I'd consistently blow half of their yearly IT budget on supporting that piece of shit, and that meant that other areas of their infrastructure had to suffer because of it. Areas that should have been updated long ago, but there was no money left over to put toward it. And all because nearly every month I'd have to install a huge update that required much SQL massaging to get it to work. Oh it came with instructions on how to install it, but they were rarely 100% accurate. So I'd spend an entire weekend every month or so doing SQL backups and restores while I tried to convince this mission critical application that it really could perform the update. (And I charged appropriate overtime rates for non-business hours events, so it sure as hell wasn't cheap.)
After the switch happened, all they needed was an installed SSL certificate and an internet connection. The rest was all done on the product website, which due to heavy AJAX usage ended up working very similar to how it already ran locally. No need for retraining their employees, and despite the higher monthly fee, it was still far FAR cheaper than paying me to install the mandatory updates on their local server. We were able to take all the previously wasted money and spend it on new workstations, new network hardware, a new server, setting up VPNs to branch offices, and less painful software to speed up other tasks that they used to perform on paper.
In the end, I probably lost somewhere around 40% of the revenue they generated for me (since it was now being spent on hardware instead of my time), but I got my fucking weekends back! woot! And since I actually cared what sort of state my client networks were in, it was rewarding to actually make visible progress in cleaning up the mess that the previous guy left behind.
So there's your plus side. As far as I'm concerned, bloated mission critical vertical market applications should ONLY be released as online services. Local installations of these things are a pain in the ass.
Actually, most game companies never touch the native Direct-X code. If you've ever used both OpenGL and Direct3D, you'll know why. D3D is an extremely low level hardware abstraction layer, much more so than OpenGL. Coding directly in D3D takes, on average, about twice as much support code as opposed to OpenGL.
Not that it really matters, since any intelligent OpenGL user never works directly with the API any more than is absolutely necessary. The source code to any recent high profile game is big... No... fucking huge ass big! So to make things a little easier to follow, everything gets wrapped up in layers. Most companies use game engines that were developed by third parties in order to reduce the need to a) hire people that are really good at the low level 3D interfaces; and b) waste huge amounts of time on an engine for a single title, thereby pushing back their prospective release date by no less than 2 years. iD is one of the few companies that makes both the engine and the game. In fact, several game engines exist that are written by companies that never produced a game themselves. Ever heard of GameBryo?
On top of that, there are countless middleware libraries that address a huge gamut of issues. SpeedTree, OpenAL, SDL, GameFace, Bink, Smacker, Miles, RakNet, ad nauseam. The point is, only a very small number of games are written to directly use OpenGL and DX without some sort of wrapper, and the number of successful commercial titles in the last 8 years that wrote everything from scratch can probably be counted on one hand.
Anyhow, out of all of these libraries, there is a huge subset that actively supports Linux. Most of these libraries are written using very generic programming techniques, or at least provide a standard interface that never changes regardless of target platform, and provides the dirty system specific implementations as a run-time or compile-time plug in. It is much to their advantage to do things this way, as these libraries are expected to not only run in Windows, but also on consoles, and by that I mean pretty much all of them.
The reason they don't just release every game for Windows for Linux as well is because these middleware libraries often come with "per platform" licenses. "For $30,000, you can use this library in 1 title on 1 platform. Kick in another $15,000 and you get another platform license. Kick in a grand total of $75,000 and you can release it on all platforms it supports." The trouble is, most games are using anywhere from 2 to 6 middleware libraries, and that ends up being a lot of cash that they're expected to recoup on Linux support. Given the demographics that generally comes with Linux desktops (dual boot rigs for people that want to game with higher % of users that run cracked software, or grandparents that only check email and perform mild web browsing), it just plain isn't worth the effort, and certainly isn't worth the investment/risk ratio.
Well then, with the exception of #7, this hits the nail right on the head. (Even #7 I can see as quite useful.) The problem with Linux has never been lack of applications or lack of effort. It's always been lack of professional polish and lack of consistent direction. I'll agree with most of the other posters that trying to emulate the Windows environment is a pointless endeavor, but Linux will never achieve high desktop penetration without emulating the one thing Windows has always been good at: consistency.
Microsoft ships a new OS about every 5-7 years. That's plenty of time for ISVs to recompile their applications, and fix the few APIs that have changed. Linux, on the other hand, comes out with a fad new distro seemingly every year, all of which want to completely shake everything up with a fresh set of new-hip-fad system libraries that are completely incompatible with any existing systems, and they all release a new version (usually completely overhauled yet again) every 6 months.
If you want Linux to seriously take off for desktop usage, then the parent's list is a great start, but in order to even achieve that with any measure of success, a real standards body would have to be formed, and it would have to (through some fairy tale pixie dust magic) garner the respect and compliance of every major distro on the market. Basically you'd be taking the 10 major distros and compressing them down into a single base image, and the only differences between them would be purely cosmetic, all underlying APIs being completely compatible on a binary level.
If somehow (as a community consisting of everyone always wanting to be the hero, developing the hottest new incompatible doo-dad that does the nifty cool thing everyone will hopefully want so we can all raise ourselves to independent stardom) we can agree on one fucking way to do things for an entire 2 years, the leaps and bounds of progress would be mind blowing. In the end we'd end up tackling pretty much everything on the parent poster's list, plus more. But, unfortunately, it won't happen. The community is far too proud and fickle to ever allow itself to be told how things are supposed to work, even if the standards were created and governed by members of the community itself.
The whole Linux community is built upon the concept of anarchy. With no direction, boundaries, or limitations, you will undoubtedly achieve great progress in coming up with new ideas and ways to do things, and you'll also get 10,000 copy-cats, slight alterations, feature additions that don't belong, and a market so flooded with options that no one can ever decide on which one to use. And yes, you can in fact have too many choices, and Microsoft, Sun, IBM, et al, already know that. (These guys are scared of Linux in the server room, not Linux on the desktop.)
And who's fault is all this chaos? Not Linus' for making Linux, and not even Stallman's for the GNU system (which is where the root of this complete chaos actually exists). It's your's. You all took a good idea, and blew it so far out of proportion that you can't even properly work together as a cohesive unit. Everyone wants to be the exotic researcher, and no one wants to be the grunt in the cubicle trenches that actually makes the shit the researchers come up into a usable product. So while I would love to see Linux rise above all of this selfish behavior and actually start to penetrate the desktop domain, I just don't see it happening. Call me a realist, or call this whole post flamebait, offtopic, whatever, but I'm going to keep using Linux for servers, and Windows, OSX, and Solaris for desktops. From the way things are now, how they've always been, and the lack of any real change on the horizon, doing anything else is just stupid.
And you didn't simply have a friend pretend to be your brother because...?
Seriously, MS doesn't really know much about your brother, all they have is a name. I've had to pretend to be different people numerous times just to make the call center lackey feel warm/fuzzy. As long as you know the right answers to any questions they might ask (which generally means you know the person pretty well and therefor wouldn't be inclined to screw them over), they have no alternative but to assume you are who you claim to be. Is it fraud? To some degree, perhaps. Though when you're doing it by the request of that person, I don't really believe lying to the customer service monkey about who you are just to accomplish the desired task is going to land you in jail any time soon.
I fail to see how having RPMs and DEBs available makes installation any easier for "most distros out there". Being a Slack user, perhaps you never noticed that new versions of libraries tend to be released every 2 to 4 months, and each distro tends to be compiled against the bleeding edge newest libraries available at that time. This generally causes an absolute ton of dependency hell at all levels. This is the exact reason why most commercial packages build against the enterprise distros, because their life cycles are counted in years instead of weeks. Having a precompiled rpm/deb in the distro repository helps, but it is far from an effective solution when it comes to newbies installing software, and it certainly doesn't make Linux a very friendly looking target for ISVs.
While rapid software evolution is the biggest strength to Linux based systems, it's ironic that it is also the absolute biggest downfall. After using Linux for over a decade on servers, and during that time even spending a 2 year stint of Linux as my only desktop OS, I can safely say that it isn't the distros' package system that's broken. Instead it's the complete lack of enforceable standards. If Linux wants to ever become a serious contender for the desktop OS throne, it will seriously need to standardize the versions of the core libraries. If you want to continue to maintain rapid development, deployment and deprecation, that's fine, but at the end of the day the distros should have a single version target for these libraries. The more bleeding edge versions can coexist on the same system right along side the legacy standards. The Linux Standard Base did a fair job at starting this, but as far as I can tell it's mostly fallen off the map, not to mention that it never went far enough.
I really hate to break the dream-bubble here guys, but we need a "Standard Linux Desktop" specification that fully defines the available libraries and their versions all the way from libc to gnome. Now I'm not saying that once you implement the standard you're done innovating, that's just stupid. What I'm saying is that a user should have a single super-package to install that brings their Linux installation into full compliance for a standard desktop specification. Multiple standard assemblies can be installed on a single machine, and would allow the use of older binaries on newer systems. In order to enforce this standard, the installation of gcc should use the latest standard assembly by default, switchable to older and custom assemblies through the use of command line switches.
Of course the biggest pain in the ass with all of this is getting all 9 million of the various distros to work together for 6 months to define these standards. Luckily we don't need to go that far. Simply getting RedHat and Debian to work together on it should be enough to affect the majority of machines out there.
Getting back on topic for the article: If you want to use a commercial package, use a distro that claims compatibility with RedHat Enterprise Linux. Otherwise pick a RHEL compatible or something based on Debian. Those are the easy picks that offer the broadest set of precompiled software that tends to work 75% of the time.
Re:Prize goes to the 3D graphics provider
on
VMware Fusion goes Beta
·
· Score: 0, Flamebait
Oh..my..god... Did you honsetly just say that AutoCAD is at the top of the parametric tool foodchain? I'm sad to inform you that you are horribly mistaken. AutoCAD is a bastard child using a mathematically inferior kernel.
Seriously. Go learn Pro/E, Catia, NX, SolidWorks, SolidEdge, UGS. Anything but AutoCAD. That thing is basically only good for doing line art. I can't count the number of times AutoCAD couldn't figure out how to properly add fillets to a solid object. Or even better, how many times it just decided to crash because it didn't want to tell me that it couldn't figure out the math (and yes, this error can be reproduced perfectly in under 2 mintes). Or better still, how many hours of my life I've wasted while waiting for it to regen the drawing. Hell, I've tried to send drawings to their support staff that explicitly point out these faults, and they didn't even want to hear about it. AutoCAD was king of the small scale desktop engineering market 15 years ago (it has never been king of high end CAD). Times have changed. I suggest you change with them.
I'd actually like to see more systems like this provide plugins exposing options for setting up configurations to simulate unreliable network connections. I used monowall quite extensively a few years ago, and it exposed a traffic shaper option to delay packets a defined amount of time, but that alone isn't sufficient for a proper simulation. And why anyone would set that to anything other than 0 when using it for firewall purposes is beyond me.
If you're going to try to shape traffic in manners like that, it would have been useful to have other options as well such as random packet dropping, packet corruption, packet reordering, and random packet delay.
I recall a few years ago that some company came up with a hardware device specifically for simulating unreliable networks with the intent of selling them primarily to game developers. I don't recall the product name though. In any event, it would be nice to see either pfSense or monowall support an official plugin to provide access to that sort of functionality. I'm not sure if *BSD has the network hooks to support all of the necessary features though.
Hrm. That is very interesting. The bit about the $300 and having a corp, I mean. For most general purposes, a corp has the same rights as an individual in the eyes of the law. It seems funny that they would get special treatment in this case.
Either way, it looks like I'll be reading up on the NFA.
I completely agree with you. The ABSOLUTE best home defense weapon is a pump action 12 gauge shotgun. Do NOT get a bird hunting gun. These weapons are very long in the barrel, and are not effective CQB (close quarters battle) weapons. It is way too hard to get around corners and through doorways with a bird gun. I recommend the Remington 870 or a Mossberg 590. They are practically the same gun, and they are heavier than bird guns so if you run out of ammo you still have a VERY effective club. Again, the key is to get as short of a barrel as possible (within the law of course). You want to be able to get through your own house with ease.
If you're going to do more than simply hide in your bedroom and yell out threats after calling the police, then please do yourself a favor: TRAIN. Don't sneak through your house slowly. Every burglar expects you to sneak around like an idiot. Walk very swiftly, almost at a jog. Practice clearing your house. Stay alive by knowing your domain by heart. Know the most effective entry points, and choke points. If you show a precision level training, you will either catch them off guard and be handing them over to the police within the hour, or you'll scare them so badly that they will NEVER come back.
Oh, and it you really want to maim someone, 00 is nice, but 32 caliber is balistically the most effective against people. At 10 meters you'll cut them into 3 pieces. That is no exageration. If you are going to shoot to kill, then use the most effective round that is legally obtainable for your weapon.
That's not exactly true if I recall correctly. It is completely legal to own fully automatic weapons in certain states. (I believe Arizona is still legal, though that may have changed.) Full auto weapons are banned by state governments, not the fed. Again, this is purely by my memory, so check with your local gun smith. Don't go to your local law enforcement agency unless you want an absolute 'no' for an answer, and then be prodded as to why you want a full auto. Cops are usually nice people, but you have to remember that every full auto out there is another one that they will percieve as a potential problem to them. They are, after all, putting their lives on the line on a daily basis, and are trained to begin interviewing EVERYONE they encounter. After a while, they'll start using interview tactics on a subconscious level.
If I'm wrong, then please do point me to a fed law that I can reference that covers this.
Slashdot Mirror
I would have to agree with this stance whole heartedly. I wrote a little bastard love child utility for Windows C++ coders, and the code itself is written in .NET because I was feeling especially lazy that day. I've since had a few people download it, most say they liked it, and only one person mentioned that I could probably make it run faster if I used a DLL from the Wine project instead of invoking the Visual Studio tools and parsing their results.
The main point being, this was a "throw away" application that I wrote one day in about an hour. I made a few bug fixes here and there, and then I've since left it to rot up on SF.net. I still occasionally use it, and apparently some other people do too. I only uploaded it because I felt that if I had a need for this, someone else out there might need it as well. Apparently I was right.
I missed this post by a few hours, so this reply will be undoubtedly buried, but I'll post my $0.02 anyhow.
The problem with Linux on the desktop is not the lack of the "killer app", as so many people are trying desperately to solve. It isn't even the GUI interface selection, or any of the other standard responses as to why Linux is flailing without much penetration into the desktop world. The #1 reason why Linux doesn't have a bigger installation base is because it has yet to penetrate the business desktop market, and that fault can be summed up into one service: Native Enterprise Authentication (ie. Active Directory for Linux).
When Windows pushed out the mainframes of its day, computing was still in its infancy, and security/privacy laws hadn't yet adapted to the computing age. Active Directory came along much later in their lineup simply because it wasn't necessary at the time. Once MS saw that site-wide authentication with integrated single sign-on was the only route left to go, they hit the nail on the head with the biggest damn hammer available. They coupled LDAP with Kerberos into a single service that provided a company directory, user authentication, and single sign-on capabilities. Later their killer app became Exchange, and Exchange could never work the way it does without Active Directory. These days we have several Linux installations that are authenticating against Active Directory, as that is the currently installed authentication system within the enterprise. Hell, there are even companies that exist solely around the concept of making this setup work as easily and flawlessly as possible.
If you want Linux to really penetrate the Enterprise desktop market (which in turn has been historically proven to increase home desktop penetration), then what Linux really needs is its own native version of Active Directory. Even if we just cloned the service it would at least make Linux/Windows integration much cleaner, but ideally it would be more than that. Either way, it would need to at least provide the same data as Active Directory, as adding a method of authenticating Windows machines against it would be necessary. This could start as simply a mash-up of Kerberos and LDAP with a management front end, but the end goal should be a stand alone service that is easy to install and easy to maintain.
There. My $0.02. Don't spend it all in once place.
Because they don't actually tell you what the case is about until you hear the opening statements?
Seriously. There are plenty of time wasting jury trials out there, and out of the whole lot of them I'd wager that only somewhere around 1% are actually worth being a part of for the sake of keeping technology unfucked.
Juries haven't been panels of peers in the computer business because they use juries built from the common populace, and that means that technologically savvy people are still a vast minority within them. If they wanted to make law a little more useful, they'd use demographically driven jury selection for cases involving specialty areas like technology.
Oh well, we'll just keep digging this hole. After all, it's "worked" thus far...
System Administrators Handbook:
* Rule #1: Never give sudo access to anyone that you would not trust to have root access. The sudo tool is merely a mechanism to provide a short barrier between the user and complete access where they could otherwise ruin the system with one mistaken command. A determined user will almost always find a way to gain a root shell if given sudo privileges.
I used to be surprised by the number of people that assumed sudo prevented other users from having root access while still being able to perform commands. These days I just chalk it up as the most misused privilege escalation technique.
You want to know what sudo is REALLY good for? It's great for giving out full root privileges without having to give out the root password. Just one less password for them to remember, that's about it. Any other reason for sudo usage is better served by a restricted setuid shell/application.
Actually, you're both right and wrong at the same time. Yes the cable company can divide up the spectrum as they see fit, but it isn't as dynamic of a change as you imply. The modem downloads a config file which dictates to it the channels it is supposed to use for this boot, and it cannot be changed without rebooting the modem. This config file also contains SLA enforcement info, like how fast it is allowed to upload, how many local MAC addresses are allowed on the LAN side, etc. Now these channels are fixed in spectrum size. Only so much data can be crammed down a channel. If you want to send more, you need to allocate a new channel. Now comes the fun, as every channel with upstream data must be rejoined with the pre-existing stream on it's way back to the head-end (remember, this is a tree network). This is a classic example of a denial of service waiting to happen. Fill one side completely (after all, it looks clear from this side branch in the tree), and the other branch has no room to insert its own data. Of course, the other branch is guaranteed its fair share, so the node will simply forcefully insert its own data by dropping someone else's data if the need arises. Scale that up on both sides and I bet you can guess what will happen... Adding more channels requires rebuilding every affected node, which requires guys in a trucks to drive out there and perform the work, which can easily cost hundreds of thousands of dollars to perform if the change required is deep into the network.
Now keep in mind that these guys still view internet as a secondary technology to television, and you'll find that the spectrum left over for high speed data is actually fairly small in comparison. There isn't as much head room available in these systems as people like to believe. Yes, it's a closed system, so you have the entire spectrum available, but useful data can only realistically fit within a small subset of the full spectrum. Anything lower in frequency is unusably slow/not enough ROI to make it worth while, and anything higher is incomprehensible from noise.
Cable systems are very different from the other media layers people are so often familiar with, which always makes explaining these issues such a task. Either way, I stated my piece and have explained the reasoning multiple times from many different angles. I leave the rest as an exercise for the reader. =)
Ah yes, the market differences. I believe you are right in that my US centric thinking (after all, I am American and I might as well live up to the stereotype) has cast a US specific scenario upon the whole situation. In the US, ISPs mostly just lease the pipe at whatever capacity they need, and the cost is flat whether they fill it 100% of the time or keep it mostly idle. There are obviously a whole slew of variables that can be applied that will adjust pricing (such as if the line is supposed to be a fail over path only, which reduces cost because the supplier can assume the line will remain mostly dormant). And of course, you can probably strike a deal for cheaper bandwidth at the tier 1/2 level by agreeing to some rule that your network throughput will look mostly like the infamous 10:1 ratio, which they'll just use to their advantage by using up the leftover :9 by suppling hosting or colocation services to others.
The main point wasn't really supposed to be about how ISPs lease their bandwidth, but rather about the radically different approach to infrastructure design that cable systems employ when compared to DSL. In the end, that's all that really matters, as it's the only constant factor in the equation. Both the DSL and cable suppliers can choose to lock themselves in to SLAs that only provide 10:1 bandwidth models, but the main factor is that the last mile in a cable system doesn't scale well for P2P, as compared to DSL (where P2P traffic truly is effectively "free").
You're comparing apples to apples and swearing to god that one of them is an orange.
First off, any ISP that pays per packet is doomed to fail just out of lack of business ability. They really do get much better deals on the bandwidth than that. What they pay for is whatever is negotiated.
Generally that ends up being: Line leasing costs for line of size X + network connection costs of $X per quarter to have that line connected at a certain transfer rate and guaranteed a minimum speed at any point in time. In other words, the connection is massive, paid for in bulk, and is assigned a certain data rate and given a Quality Of Service level that is guaranteed in writing the Service Level Agreement.
Any company that charges its end users per MB or kB for traffic in either direction is only doing so because of a few possible reasons. Most notably: A) they are severely overselling their capabilities in order to keep the price low, and need to keep a tight leash on users to maintain the illusion of a decent infrastructure; or B) they are way too greedy and managed to convince their end users that this billing model is "OK".
So once again, no, ISPs don't pay per packet, the lease a physical wire from some entity, and pay someone (often that same entity, but not always) to plug the other end into an edge router that is in some way, shape, or form, eventually hooked up to the internet. The amount they pay to this higher tier ISP will determine the amount of throttling that takes place on that line.
All of this means that any traffic that leaves (or enters) their network through that leased line incurs no additional cost by itself. It isn't like they pay $0.02 cents per packet. The line is paid for in full regardless of whether it is kept at 5% capacity or 100% capacity. The extra outbound packet does nothing at this point but raise the water level just a little bit more. Eventually, when combined with all the other packets from their other customers, it will saturate the line, and thus require they either change their policies or beat down their users for hogging too much bandwidth, but again, the packet itself has no additional cost.
And this is just like... you guessed it: keeping the packet on the internal network. At this level, the company is leasing a line to YOU, and that line is (supposedly) going to provide you with unbelievable speed at an unbelievable discount. And it's all unbelievable because (like all things that are too good to be true) it really isn't true. The connection at their head-end, and often (especially in cable systems) the line itself is severely oversold. But in the end, this works out. Most people check their email, read cnn.com for 30 minutes, and go to watch TV for the rest of the night. This is the conventional traffic demographic. They oversell the lines because statistically, no one is going to hog their entire share for any great length of time. The lines themselves are an investment of the owning company, and they pay for them regularly by maintaining them with their own crews. (See? Apples to apples, not apples to oranges. Both connections are paid for as a bulk commodity, not as an itemized list of packets that pass through them.)
This is what bring us back to my original statement. In a DSL system, the line that YOU lease is physically separate from the other subscribers up until it reaches the head-end. Your last mile is guaranteed available just to you. You can cram that line full of traffic to your heart's content, and as long as the traffic you generate never really leaves the head-end out the Internet on-ramp line, no one is going to care. (Unless they are overselling the capabilities of their DSLAM, but that's a different limitation entirely.) However, in CABLE systems, there is no such thing as a dedicated line. The last mile is shared amongst all subscribers. When you cram your share full of traffic, you affect your neighbor and the neighborhood across the street, and even the people across town. As your packets travel toward the head-end,
Seriously, do these "researchers" even HAVE cable internet? Upstream is only user segregated to the head-end for bare copper technologies like DSL. Cable broadband is built on a tree network. Sure, you can build more nodes into the infrastructure to free up a bit more upstream within a single neighborhood, but eventually that upstream has to be combined with the upstream from all the other nodes. Eventually you just can't squeeze any more data into the upstream band and everything stalls. This is one of the reasons why you don't see SDSL equivalents in cable systems. They always give you more downstream than upstream because downstream is cheap for them. Massive upstream requires a lot more infrastructure investment, which heavily cuts into their profit margins. And yes, the data has to go all the way back to the head-end before it can be resent to an IP in the same cable system, even if they are on the same node.
P2P just isn't useful for cable systems. They're better served by caching technologies like transparent proxy servers.
Yes, it can go through the clipboard, and it often does as that's the easiest way to paste text into a random text box. However, there are other methods of moving data that do not require the use of the clipboard. For instance, Win32API provides applications with the ability to pass messages directly to other windows. Since every control is a window (more or less), you can actually inject the keydown/keyup messages directly into the desired control without ever touching the OS's keyboard hooks or the clipboard. All you need is the target HWND, which the user could easily supply through some global hotkey that triggers a focus probe.
Still, even that doesn't really solve the problem. All I did there was move it. The OS could still be hooked for all messages. In the end, nothing you do can make an unknown terminal secure. If you didn't bring your own laptop, known to be secure, and use network encryption with preshared keys, you're just asking to be spied upon. It's just a matter of how much effort the eavesdropper wants to expend to get your data.
and
These two concepts are mutually exclusive. GPL'ing Solaris will undoubtedly create a thousand distributions. I believe the biggest problem people have in understanding the situation is that Solaris is an OS, not just a kernel (like Linux). Sun doesn't have to beat Linux as a whole to complete their stated objective. They just need to surpass the top Linux distribution (probably Ubuntu or RedHat).
/opt). Use symlinks if you want to make some CLI stuff available to the users, and GUI apps just plain don't need it. (Hey wait, that sounds like a Mac! (no shit...))
The rest of your post is a mixed bag as well.
There are quite a few useful CLI tools that have no GNU replacement. For example: dtrace is insanely useful, and I challenge you to show me some level of equivalence from the GNU tools. The only CLI tools I can see as good candidates for replacement are the non-OS specifics. Things like grep, sed, awk, less, more, etc.
zshell as the default shell, I'll bite. Why not. If I hate it, I can always run back to tcsh.
I also see no reason to join Solaris and OpenSolaris at the hip under a single name. It is more advantageous for them to remain separate entities so that companies know that moving to OpenSolaris means that their custom scripts and etc will not necessarily work exactly as written for their previous Solaris environment. Give them another Solaris version, 10 years of support, and then start to kill it off. OpenSolaris should be the new direction, but there needs to be a distinct line that identifies them as separate operating systems.
APT as a distribution system: that or YUM, I don't care. Just oh please god, for fuck's sake, kill off pkgadd. That thing is about 10 miles away from being anything more than a nightmare designed to give the sys admins bulletproof job security. The one and only bitch that I will continue to maintain about Unix style package systems is the idea that software is managed by the same database as the OS patches. I shouldn't need to dig through 900 pkgs/RPMs/debs/whatever just to uninstall Open Office. Use the same package system if you must, but please start doing a better job of application separation. The OS needs to come with a finite set of tools, and after that all additional dependencies just plain need to be packaged with the application that requires them, and nicely installed into a separate directory tree (*cough*
Unifing GTK and QT with the same, one and only default theme that looks good: not a priority. I have a better solution. Pick one. Yes, pick one. QT or GTK, not both. Why? Because the separate GUI camps are doing just as much damage as they are helping. Sure, we end up with all sorts of nifty advances in GUI methodology, but at the end of the day, they never look the same even when the themes are designed to match, and they all try to fix duplicate problems by providing their own sounds systems, clipboards, etc, which seem to never want to work together correctly. (In my opinion, Qt should have been a system stacked on to of GTK, but too late now.) Just pick one and use it exclusively. ISV developers enjoy some level of scarceness in options, especially when it comes to something that should be as elementary as which GUI library their app is supposed to be written upon.
Marketing army: One word. YES! If they manage to take the x86 Unix as a desktop concept and unfuck it, you bet your ass they should jump up and down and throw chairs and all sorts of Ballmerisms. I believe they would have earned the right to be excited about something as monumental as that. Mac did a great job at their endeavor, but they control all the hardware, so it wasn't much different than making the current Solaris look p
Not to nitpick this exact post, as I'm seeing this all over, but...
Well frankly, I don't see the issue with BLOB drivers. If a BLOB driver can crash your system, that isn't entirely the shitty driver developer's fault. Sure, they wrote the crap code that doesn't work, but the OS (and to some degree, the bus design) is at fault for giving up that much control to the driver in the first place. There are very few drivers that truly require full control of the entire system in order to work. A good system design coupled with a good OS can gracefully segregate all software and hardware failures until the very last straw (at which point your system is so fucked that nothing useful remains anyhow, so who cares).
If your video card driver fails, just dump the driver blob, reset the hardware slot, and reload the driver. If the underlying software isn't capable of recovering from a hardware failure of that magnitude, we'll say X.org, then I guess X.org is going to crash. Good thing that's not much unlike hitting Ctrl-Alt-Backspace, and gdm will just restart it. If the device continues to fail, the OS simply flags the device error and turns it off until a sys admin deals with it.
The same can be done for hard-drive controllers, sound cards, web-cams, network cards, etc. Kill the driver, reset the device (look! a known device state!) and reload the driver. This isn't a new concept. Plenty of big iron already does this sort of "magic" (and has for years), and it works surprisingly well. The reason that it doesn't work for Linux is because most people assume Linux == an x86 clone, which doesn't provide a system bus capable of this sort of individual device reset, and probably never will simply because the primary market segment doesn't need (or even know about) this level of system stability.
Consequently, this bus model is the same one that provides hot swap on "integral" hardware devices. Yes, it does exist, and it can hot swap memory, CPUs, video cards, network devices, etc. And although you do reap the consequences of these swaps (ripping out a stick of RAM is generally going to cause some app to crash), however if you let the OS know what you are going to do before you actually do it you'd be surprised with what you can get away with without having to touch the power button.
If you want someone to bitch at for making your PC unstable, don't look at the driver vendor or the OS (at least not yet). The driver vendor just wrote a driver that (supposedly) works for the given platform, and the OS is (supposedly) just doing everything that it can to make a stable system out of what is available. If you want somewhere to point the finger, point it at the architecture designers *cough* Intel/AMD *cough*. They're the ones that dictate how free you will ever be from misbehaving devices/drivers bringing down your whole system. Until x86 receives a hot-pluggable bus, there's really only so much that can be done.
Even the best fully open source driver in existence will bring down an entire system if a piece of hardware fails. That's the way the architecture is designed. Sorry to burst the bubble of the flamers. *shrug*
So when I found out that he was allowing students to use graphing calculators on the final exam since, "they won't help you anyways", I spent the last week of class time slowly entering all of the functions into my TI-85 so I could refer to them later. Turns out what I did was "damn smart (tm)", because he used every single last one of them on the exam multiple times.
That was the last time I used most of those equations. I still use a few here and there, but never frequently enough to really remember anything past the basic use cases of sin/cos and what their output looks like. In the end I feel that I have accomplished the requirements of high school level trig, as I understand how and why trig works, but asking people to remember those equations is unrealistic and it made the class artificially difficult.
I think the point was supposed to be something about how the libraries commonly used already do support multiple compile targets (usually including Linux), but the licensing costs outweigh the expected ROI due to the market demographics for Linux users.
I never read TFA, so I was expecting -1: Off-topic, but with karma to burn, who cares? =)
As for the DX layer I was referencing, I was talking about Immediate mode, not Retained. From my experience, Immediate mode requires far more operations to achieve the same result as compared to OpenGL. Not that any of it really matters, as neither system is very easily used when inlined directly into the game code. You'd end up writing the same 10 lines of code 50+ times all over the place, when in reality that should just been made into a function call.
I used to do network/systems support for local area businesses, many of them being insurance agencies. When I heard that one of my biggest clients was moving from a local installation of their primary software package to software as a service, I was a very happy man. I'd consistently blow half of their yearly IT budget on supporting that piece of shit, and that meant that other areas of their infrastructure had to suffer because of it. Areas that should have been updated long ago, but there was no money left over to put toward it. And all because nearly every month I'd have to install a huge update that required much SQL massaging to get it to work. Oh it came with instructions on how to install it, but they were rarely 100% accurate. So I'd spend an entire weekend every month or so doing SQL backups and restores while I tried to convince this mission critical application that it really could perform the update. (And I charged appropriate overtime rates for non-business hours events, so it sure as hell wasn't cheap.)
After the switch happened, all they needed was an installed SSL certificate and an internet connection. The rest was all done on the product website, which due to heavy AJAX usage ended up working very similar to how it already ran locally. No need for retraining their employees, and despite the higher monthly fee, it was still far FAR cheaper than paying me to install the mandatory updates on their local server. We were able to take all the previously wasted money and spend it on new workstations, new network hardware, a new server, setting up VPNs to branch offices, and less painful software to speed up other tasks that they used to perform on paper.
In the end, I probably lost somewhere around 40% of the revenue they generated for me (since it was now being spent on hardware instead of my time), but I got my fucking weekends back! woot! And since I actually cared what sort of state my client networks were in, it was rewarding to actually make visible progress in cleaning up the mess that the previous guy left behind.
So there's your plus side. As far as I'm concerned, bloated mission critical vertical market applications should ONLY be released as online services. Local installations of these things are a pain in the ass.
Actually, most game companies never touch the native Direct-X code. If you've ever used both OpenGL and Direct3D, you'll know why. D3D is an extremely low level hardware abstraction layer, much more so than OpenGL. Coding directly in D3D takes, on average, about twice as much support code as opposed to OpenGL.
Not that it really matters, since any intelligent OpenGL user never works directly with the API any more than is absolutely necessary. The source code to any recent high profile game is big... No... fucking huge ass big! So to make things a little easier to follow, everything gets wrapped up in layers. Most companies use game engines that were developed by third parties in order to reduce the need to a) hire people that are really good at the low level 3D interfaces; and b) waste huge amounts of time on an engine for a single title, thereby pushing back their prospective release date by no less than 2 years. iD is one of the few companies that makes both the engine and the game. In fact, several game engines exist that are written by companies that never produced a game themselves. Ever heard of GameBryo?
On top of that, there are countless middleware libraries that address a huge gamut of issues. SpeedTree, OpenAL, SDL, GameFace, Bink, Smacker, Miles, RakNet, ad nauseam. The point is, only a very small number of games are written to directly use OpenGL and DX without some sort of wrapper, and the number of successful commercial titles in the last 8 years that wrote everything from scratch can probably be counted on one hand.
Anyhow, out of all of these libraries, there is a huge subset that actively supports Linux. Most of these libraries are written using very generic programming techniques, or at least provide a standard interface that never changes regardless of target platform, and provides the dirty system specific implementations as a run-time or compile-time plug in. It is much to their advantage to do things this way, as these libraries are expected to not only run in Windows, but also on consoles, and by that I mean pretty much all of them.
The reason they don't just release every game for Windows for Linux as well is because these middleware libraries often come with "per platform" licenses. "For $30,000, you can use this library in 1 title on 1 platform. Kick in another $15,000 and you get another platform license. Kick in a grand total of $75,000 and you can release it on all platforms it supports." The trouble is, most games are using anywhere from 2 to 6 middleware libraries, and that ends up being a lot of cash that they're expected to recoup on Linux support. Given the demographics that generally comes with Linux desktops (dual boot rigs for people that want to game with higher % of users that run cracked software, or grandparents that only check email and perform mild web browsing), it just plain isn't worth the effort, and certainly isn't worth the investment/risk ratio.
End of story.
So... what was TFA about?
Well then, with the exception of #7, this hits the nail right on the head. (Even #7 I can see as quite useful.) The problem with Linux has never been lack of applications or lack of effort. It's always been lack of professional polish and lack of consistent direction. I'll agree with most of the other posters that trying to emulate the Windows environment is a pointless endeavor, but Linux will never achieve high desktop penetration without emulating the one thing Windows has always been good at: consistency.
Microsoft ships a new OS about every 5-7 years. That's plenty of time for ISVs to recompile their applications, and fix the few APIs that have changed. Linux, on the other hand, comes out with a fad new distro seemingly every year, all of which want to completely shake everything up with a fresh set of new-hip-fad system libraries that are completely incompatible with any existing systems, and they all release a new version (usually completely overhauled yet again) every 6 months.
If you want Linux to seriously take off for desktop usage, then the parent's list is a great start, but in order to even achieve that with any measure of success, a real standards body would have to be formed, and it would have to (through some fairy tale pixie dust magic) garner the respect and compliance of every major distro on the market. Basically you'd be taking the 10 major distros and compressing them down into a single base image, and the only differences between them would be purely cosmetic, all underlying APIs being completely compatible on a binary level.
If somehow (as a community consisting of everyone always wanting to be the hero, developing the hottest new incompatible doo-dad that does the nifty cool thing everyone will hopefully want so we can all raise ourselves to independent stardom) we can agree on one fucking way to do things for an entire 2 years, the leaps and bounds of progress would be mind blowing. In the end we'd end up tackling pretty much everything on the parent poster's list, plus more. But, unfortunately, it won't happen. The community is far too proud and fickle to ever allow itself to be told how things are supposed to work, even if the standards were created and governed by members of the community itself.
The whole Linux community is built upon the concept of anarchy. With no direction, boundaries, or limitations, you will undoubtedly achieve great progress in coming up with new ideas and ways to do things, and you'll also get 10,000 copy-cats, slight alterations, feature additions that don't belong, and a market so flooded with options that no one can ever decide on which one to use. And yes, you can in fact have too many choices, and Microsoft, Sun, IBM, et al, already know that. (These guys are scared of Linux in the server room, not Linux on the desktop.)
And who's fault is all this chaos? Not Linus' for making Linux, and not even Stallman's for the GNU system (which is where the root of this complete chaos actually exists).
It's your's.
You all took a good idea, and blew it so far out of proportion that you can't even properly work together as a cohesive unit. Everyone wants to be the exotic researcher, and no one wants to be the grunt in the cubicle trenches that actually makes the shit the researchers come up into a usable product. So while I would love to see Linux rise above all of this selfish behavior and actually start to penetrate the desktop domain, I just don't see it happening. Call me a realist, or call this whole post flamebait, offtopic, whatever, but I'm going to keep using Linux for servers, and Windows, OSX, and Solaris for desktops. From the way things are now, how they've always been, and the lack of any real change on the horizon, doing anything else is just stupid.
And you didn't simply have a friend pretend to be your brother because...?
Seriously, MS doesn't really know much about your brother, all they have is a name. I've had to pretend to be different people numerous times just to make the call center lackey feel warm/fuzzy. As long as you know the right answers to any questions they might ask (which generally means you know the person pretty well and therefor wouldn't be inclined to screw them over), they have no alternative but to assume you are who you claim to be. Is it fraud? To some degree, perhaps. Though when you're doing it by the request of that person, I don't really believe lying to the customer service monkey about who you are just to accomplish the desired task is going to land you in jail any time soon.
I fail to see how having RPMs and DEBs available makes installation any easier for "most distros out there". Being a Slack user, perhaps you never noticed that new versions of libraries tend to be released every 2 to 4 months, and each distro tends to be compiled against the bleeding edge newest libraries available at that time. This generally causes an absolute ton of dependency hell at all levels. This is the exact reason why most commercial packages build against the enterprise distros, because their life cycles are counted in years instead of weeks. Having a precompiled rpm/deb in the distro repository helps, but it is far from an effective solution when it comes to newbies installing software, and it certainly doesn't make Linux a very friendly looking target for ISVs.
While rapid software evolution is the biggest strength to Linux based systems, it's ironic that it is also the absolute biggest downfall. After using Linux for over a decade on servers, and during that time even spending a 2 year stint of Linux as my only desktop OS, I can safely say that it isn't the distros' package system that's broken. Instead it's the complete lack of enforceable standards. If Linux wants to ever become a serious contender for the desktop OS throne, it will seriously need to standardize the versions of the core libraries. If you want to continue to maintain rapid development, deployment and deprecation, that's fine, but at the end of the day the distros should have a single version target for these libraries. The more bleeding edge versions can coexist on the same system right along side the legacy standards. The Linux Standard Base did a fair job at starting this, but as far as I can tell it's mostly fallen off the map, not to mention that it never went far enough.
I really hate to break the dream-bubble here guys, but we need a "Standard Linux Desktop" specification that fully defines the available libraries and their versions all the way from libc to gnome. Now I'm not saying that once you implement the standard you're done innovating, that's just stupid. What I'm saying is that a user should have a single super-package to install that brings their Linux installation into full compliance for a standard desktop specification. Multiple standard assemblies can be installed on a single machine, and would allow the use of older binaries on newer systems. In order to enforce this standard, the installation of gcc should use the latest standard assembly by default, switchable to older and custom assemblies through the use of command line switches.
Of course the biggest pain in the ass with all of this is getting all 9 million of the various distros to work together for 6 months to define these standards. Luckily we don't need to go that far. Simply getting RedHat and Debian to work together on it should be enough to affect the majority of machines out there.
Getting back on topic for the article: If you want to use a commercial package, use a distro that claims compatibility with RedHat Enterprise Linux. Otherwise pick a RHEL compatible or something based on Debian. Those are the easy picks that offer the broadest set of precompiled software that tends to work 75% of the time.
Oh..my..god...
Did you honsetly just say that AutoCAD is at the top of the parametric tool foodchain? I'm sad to inform you that you are horribly mistaken. AutoCAD is a bastard child using a mathematically inferior kernel.
Seriously. Go learn Pro/E, Catia, NX, SolidWorks, SolidEdge, UGS. Anything but AutoCAD. That thing is basically only good for doing line art. I can't count the number of times AutoCAD couldn't figure out how to properly add fillets to a solid object. Or even better, how many times it just decided to crash because it didn't want to tell me that it couldn't figure out the math (and yes, this error can be reproduced perfectly in under 2 mintes). Or better still, how many hours of my life I've wasted while waiting for it to regen the drawing. Hell, I've tried to send drawings to their support staff that explicitly point out these faults, and they didn't even want to hear about it. AutoCAD was king of the small scale desktop engineering market 15 years ago (it has never been king of high end CAD). Times have changed. I suggest you change with them.
I'd actually like to see more systems like this provide plugins exposing options for setting up configurations to simulate unreliable network connections. I used monowall quite extensively a few years ago, and it exposed a traffic shaper option to delay packets a defined amount of time, but that alone isn't sufficient for a proper simulation. And why anyone would set that to anything other than 0 when using it for firewall purposes is beyond me.
If you're going to try to shape traffic in manners like that, it would have been useful to have other options as well such as random packet dropping, packet corruption, packet reordering, and random packet delay.
I recall a few years ago that some company came up with a hardware device specifically for simulating unreliable networks with the intent of selling them primarily to game developers. I don't recall the product name though. In any event, it would be nice to see either pfSense or monowall support an official plugin to provide access to that sort of functionality. I'm not sure if *BSD has the network hooks to support all of the necessary features though.
Hrm. That is very interesting. The bit about the $300 and having a corp, I mean. For most general purposes, a corp has the same rights as an individual in the eyes of the law. It seems funny that they would get special treatment in this case.
Either way, it looks like I'll be reading up on the NFA.
I completely agree with you. The ABSOLUTE best home defense weapon is a pump action 12 gauge shotgun. Do NOT get a bird hunting gun. These weapons are very long in the barrel, and are not effective CQB (close quarters battle) weapons. It is way too hard to get around corners and through doorways with a bird gun. I recommend the Remington 870 or a Mossberg 590. They are practically the same gun, and they are heavier than bird guns so if you run out of ammo you still have a VERY effective club. Again, the key is to get as short of a barrel as possible (within the law of course). You want to be able to get through your own house with ease.
If you're going to do more than simply hide in your bedroom and yell out threats after calling the police, then please do yourself a favor: TRAIN. Don't sneak through your house slowly. Every burglar expects you to sneak around like an idiot. Walk very swiftly, almost at a jog. Practice clearing your house. Stay alive by knowing your domain by heart. Know the most effective entry points, and choke points. If you show a precision level training, you will either catch them off guard and be handing them over to the police within the hour, or you'll scare them so badly that they will NEVER come back.
Oh, and it you really want to maim someone, 00 is nice, but 32 caliber is balistically the most effective against people. At 10 meters you'll cut them into 3 pieces. That is no exageration. If you are going to shoot to kill, then use the most effective round that is legally obtainable for your weapon.
That's not exactly true if I recall correctly. It is completely legal to own fully automatic weapons in certain states. (I believe Arizona is still legal, though that may have changed.) Full auto weapons are banned by state governments, not the fed. Again, this is purely by my memory, so check with your local gun smith. Don't go to your local law enforcement agency unless you want an absolute 'no' for an answer, and then be prodded as to why you want a full auto. Cops are usually nice people, but you have to remember that every full auto out there is another one that they will percieve as a potential problem to them. They are, after all, putting their lives on the line on a daily basis, and are trained to begin interviewing EVERYONE they encounter. After a while, they'll start using interview tactics on a subconscious level.
If I'm wrong, then please do point me to a fed law that I can reference that covers this.