You'll be wanting PC-BSD, then. It's FreeBSD with tweaks for desktop use, a different installer, and some extra utilities. It's more of an add on to FreeBSD than a separate project like Ubuntu is to Debian.
If you're used to Debian, bear in mind that updating FreeBSD isn't as streamlined as running apt and walking away. It's not difficult, but it's not as automated as Debian.
My advice: stay away from ports unless you need specific options for a piece of software. The way ports interacts with the package system is a bit unintuitive; it works fine, but it'll confuse you if you're not accustomed to it. If you do use ports, only make the changes you actually need - sometimes the options it gives you will make the port not compile.
As an aside, you do realize that you can run Debian with pretty much any desktop, right? It doesn't have to be GNOME 3. If you can live with systemd (most people don't have too much trouble with it - I only had trouble when migrating to it), that might be the best option for you.
Standard Emacs is incomprehensible to me. I can't get what sick mind desided on the keyboard short cuts.
The same sick mind that used to spend a lot of time working with Symbolics LISP machines. Look up the "space cadet" keyboard sometime.
The tutorial really tries to get you to ignore the special keys on your keyboard. Page Up/Down, the arrow keys, Home, and End all work fine in Emacs, but the tutorial will have you doing C-v, C-n, etc. That makes sense if you're working with antique terminals. It doesn't make much sense today. Except for the glaringly obvious cut-and-paste commands, for normal use it acts more or less like any "normal" text editor.
There is some semblance of sense in the default keybindings. C-x is full of (usually) global functions. C-c is for mode-specific keybindings. Very common things have their own single combination keybindings (movement, saving, cut/paste, etc.). There's also some really confusing ones that require you to understand how Emacs works (like C-u for "prefix argument" that does different things to different commands). And of course, C-g, which stops Emacs from doing whatever it's doing to piss you off at the moment.
Honestly, I don't bother with most of the Emacs keybindings. I've memorized the ones I need (like C-c C-e l o to export an org-mode document to pdf) and use the vim equivalents for regular editing. I've got evil-leader installed, which will let me bind functions to the comma (as in, ",e" to export to pdf), but I never get around to actually setting it up.
2K was the future of Windows. Microsoft was attempting to move everyone from the old 9x architecture to NT. Yes, it uses different drivers (it's a different operating system altogether, just with some compatability stuff and the Win32 API), but your average user didn't know that. Microsoft went to great pains to make the transition between 9x and NT as transparent as possible.
ATI effectively abandoned the product when they didn't write drivers for it. That decision had consequences - one of which was losing me as a customer.
I didn't think of trying a driver for just one of the chips. Nothing showed up in any of my searches talking about that. Of course, that was fifteen years ago, so I don't remember everything I tried.
It's not the reason I don't buy AMD cards. It's not even the same company making them. But since I don't use them myself, I only have the word of other people to go on, and I haven't heard very many people saying good things about AMD video.
Yeah, I had a Rage Fury MAXX (or something like that) that only had Windows drivers for 98.
Didn't matter on Linux, but I had some work to do on IIS for work and installed W2K Server on a second drive and set up dual boot. It gave me 640x480, 16 colors.
Their excuse: it's a gaming card, and people only game on Windows 98.
It really didn't matter that much to me from a practical standpoint - my home machine was Linux-only most of the time. But I decided since ATI wanted to dictate what their users could use their products for, I didn't need ATI.
Blender now supports OpenCL on AMD cards, so I could theoretically switch now, but I never hear good things about AMD. I'll stick with NVidia.
Last time I checked (admittedly, years ago), the problem was that no one works on HURD. I don't know why. I think they had four people working on it sporadically when they did the 0.4 release.
It's not as if the basic concepts won't work, especially with fast machines like we have today. It's not even as if HURD is trying some new, revolutionary design - microkernel architectures have been implemented before (MINIX is a good example here). But for some reason, HURD just doesn't draw in the developers. And while a lot of code from Linux drivers would work in HURD drivers, there would still have to be significant work on each one - and that's assuming the basic infrastructure for what the driver does even exists.
Will we see a future open source release of HP-UX, perhaps?
Doubtful. It'd take a team of software experts and lawyers a lot of time to verify HP's ownership of any source code that was released.
Sure, Sun did it with Solaris, but Sun has always been a lot friendlier with open source than HP and already had some large open source products out there (Java, for instance, and OpenOffice).
I haven't done a lot of work with HP-UX - just some support stuff. Is there anything there that's worth bothering with?
Emacs and vi are mostly useful to people who have to edit a lot of text. If you're only editing occasionally, or you usually use a "normal" editor, you'll never learn them.
I learned vi because I was a sysadmin and worked with UNIX all day. Every UNIX machine has vi, and it used to be common for it to be the only visual editor on the system (especially if you were working with commercial UNIX like HP-UX or Solaris, like I was). I would never have put in the time to learn it otherwise - I was happily editing files with pico before I learned vi.
I only learned emacs because of vi - I needed something with the power of an IDE, a good macro or scripting system, and vi keybindings (my fingers have hit the escape key three times so far while editing this comment - it's burned into my brain). Editing text was the primary part of my job. Emacs with evil-mode does that for me. Of course, I had to learn elisp, but I'll take that over vimscript any day. I find I actually enjoy the language.
The point is not that the public should embrace the use of drugs but that the war on drugs is a complete failure and actually doing harm. It only makes sense that you should try something else when what you're doing isn't working.
Yep. Unfortunately, there's a lot more to it.
First off, there are of course the people who benefit from the current system. The criminal justice system is huge, and there are a lot of people and companies that suck on that teat.
Second, decriminalization is "soft on crime." That's political suicide in many parts of the country.
Third, a lot of conservative types support the war on drugs and long prison sentences. Those play well with the Republican base.
Also:
For example, we could legalize marijuana and decriminalize other drugs and use the income from taxes on marijuana to fund education to prevent abuse and social programs to help abusers get back on their feet and be proud of themselves and break their addiction (and, possibly more importantly, their need for their addiction.)
Ideally we'd try lots of different methods of helping people and use studies to see which methods are actually effective and worth continued funding.
You used the words "social programs." It doesn't matter how it's funded, it'll be classified as "socialism." Most Americans have a dim idea of what socialism actually is, but they know they hate it. Once the s-bomb is dropped, you've lost a lot of support.
I don't have any ideas for what to do about drug dealers who can no longer make a profit selling drugs, though. It'd suck to collapse that economy and drive them to a worse crime.
I don't know much about the larger drug network, but I do know a few small time dealers. The ones that don't already have regular jobs would probably just join the regular workforce. That's completely anecdotal, though.
And honestly, we already tax alcohol and tobacco and I have to wonder where all of that money is going.
We went to the moon, then stopped, and haven't left LEO since. It's been forty-six years. We're currently incapable of going to the moon, because we lack the infrastructure and experience necessary. If we'd established an actual permanent base, we would have had reason to keep going. We'd probably have had feet on Mars already.
Don't get me wrong - I'm a big fan of the rovers - but you're just not going to get the scientific data and technological development that you would get if people were there on a permanent basis. Mars is harder to colonize, though, since it's has a higher gravity and is in a different solar orbit. If we had the experience of a permanent moon base, we might be able to pull if off.
It's user-level code I was thinking of. A lot of problems people are talking about aren't kernel-level, but related to bugs in the system libraries or applications.
If applications used TAI for time and converted only for output, many of these problems would go away, or at least change "bug that crashes the server" into "bug that prints occasional wrong time value on reports." The latter is a lot more visible and would be easier to troubleshoot and get fixed.
Databases are an example here: if databases used TAI instead of UTC for time values, it would eliminate a lot of the problems other people have been talking about in this discussion.
Regarding Macs: I remember Steve Jobs saying at some point that Macs were Y2K compliant and had been from the start. Given that early Macs weren't 32 bit (and with classic MacOS not having any UNIX heritage), I wouldn't be surprised at all to find they use a formatted time. I'd be very surprised if OSX didn't use UNIX time at the core, though - having formatted time in a low-level library (for compatibility with classic apps) makes sense, though. But this is all speculation on my part.
Ever heard that saying, "Emacs is a great OS but it lacks a decent text editor?" Well, thanks to evil-mode, now it has one.
I haven't seen much argument about evil-mode vs vanilla emacs. I think the consensus is pretty much, "it's all emacs." Emacs users generally customize their keybindings anyway - evil-mode is just a bit more extreme than most.
As for me, I like vim. I instinctively use vi keys when editing. However, I need custom scripts for some of the work I do, and I hate vimscript. Emacs gives me an editor that uses vi keys but lets me do customizations in elisp. It also has some other kick ass features I've come to like (org-mode is amazing). I still use vim for quick editing and sysadmin type stuff, but I write code and documents in emacs.
I'm sure it's better (I didn't use emacs before packages), but going from vanilla emacs to working IDE still takes a quite a bit of research and work.
Company or ac? Ido or Helm? Built-in CEDET, development version of CEDET (hope you don't do scheme development, 'cause semantic shits on it), or clang-based autocomplete? CEDET project management or projectile? Don't forget flymake - oops, that's outdated, now use flycheck, but wait, that's not compatible with...
Emacs is great, but for someone like OP who is used to "install xcode and run with it," roll-your-own probably isn't the way to go. That's why I mentioned spacemacs.
Emacs might suit your needs as well, but getting it set up with all the bells and whistles of an IDE is a bit of a pain. There are projects that help with that, however, like spacemacs (defaults to vi keybindings, but supports emacs keybindings as well). I use emacs with a custom config, but I haven't done much C++ since I switched from vim. What I have done has worked OK, but I'm sure my config has room for improvement.
QT Creator is cross platform and supports C++. It can do non-QT projects just fine.
There's Anjuta and KDevelop as well, but I haven't used either of those in quite some time and have no idea what the status is. KDevelop used to be used quite a bit for KDE development, which is C++.
It looks like a javascript emacs. Anyone know how it compares in "hackability?" Are there github sites full of javascript mods for it like the elisp ones for emacs?
I'm not a fan of javascript, but I can see this being handy for someone who is.
We have a time standard that doesn't use leap seconds - Atomic Time (TAI). We can convert between the two fairly easily.
So why not instead push for software to use TAI in place of UTC, and then convert for output or whatever? We could just have leap seconds in our time zone files and forget about the machine actually experiencing 23:59:60 at all.
It was "cheaper" if all our service area was in Tulsa, so that's where our service area was. That's about a two hour drive from where my company was based.
There are doctors here that accept that network, we just couldn't use them. My sister has the same insurance provider and has access to local doctors.
I've talked to people in other jobs who have had similar arrangements. Some are lucky, and are given the choice to pay extra for local service. Some, like me, didn't have that option.
I could have changed jobs, if I was willing to relocate or change careers. Having to change careers or move because you need better health care is not a point in favor of our current system.
That's funny, I know a lot of Americans that have gotten shitty and incompetent health care, misdiagnoses, and poor coverage. As long as we're throwing around anecdotes, I know one guy that was forced to turn down a good job offer because their insurance wouldn't cover his cancer meds. I also know a woman who only stays with her abusive cheating husband because she can't afford insurance for her Crohn's disease.
I never understand arguments like yours. Our health care system sucks. It's just as prone to poor care as any other system. It reduces freedom of the individual (unless you count corporate "individuals," where it adds one more control over their employees). It's expensive, it doesn't cover everyone, and we all end up picking up the tab for the uninsured anyway. It ties health care to employment, which is ridiculous - people making close to minimum wage can't afford it without subsidies, and if you lose your job, you lose your insurance. And the insurance companies will do everything they can to discourage you from going to the doctor in the first place; that's what the deductible is for, as well as the common practice of having all the "in network" doctors based in another city.
No system is perfect, but ours is just downright bad. You want to say the Canadian system sucks, go ahead - but don't pretend that ours is great.
I agree with you for the most part. However, while we might have solved the problem of "getting to the moon," we've never solved the problem of "staying on the moon," which is a different thing completely.
The hard part isn't getting people there. We can do that with today's technology - not cheaply, but we can do it. The hard part is keeping them alive on a world with a hostile environment that lacks many of the basic requirements for life.
Both a moon base mission or a Mars mission would require putting people in a completely closed self-sustaining environment (while we could resupply a moon base a lot easier than a Mars base, it's not economical to do so, and they would need to be able to survive if a shipment or two was missed). Either mission would place humans in a high radiation, low pressure, cold environment. Either mission would place humans in a low gravity situation for extended periods. All in all, we'd face tougher challenges on the moon, but we'd have a better chance to respond in emergencies. Considering the bad PR NASA would get if they lost a crew, that last bit is important.
That said, I don't propose changing focus at this stage of the game, simply because constantly changing objectives is a recipe for accomplishing nothing. The above arguments apply the other direction as well, so technology developed creating a Mars base will help with developing a moon base.
Slashdot Mirror
You'll be wanting PC-BSD, then. It's FreeBSD with tweaks for desktop use, a different installer, and some extra utilities. It's more of an add on to FreeBSD than a separate project like Ubuntu is to Debian.
If you're used to Debian, bear in mind that updating FreeBSD isn't as streamlined as running apt and walking away. It's not difficult, but it's not as automated as Debian.
My advice: stay away from ports unless you need specific options for a piece of software. The way ports interacts with the package system is a bit unintuitive; it works fine, but it'll confuse you if you're not accustomed to it. If you do use ports, only make the changes you actually need - sometimes the options it gives you will make the port not compile.
As an aside, you do realize that you can run Debian with pretty much any desktop, right? It doesn't have to be GNOME 3. If you can live with systemd (most people don't have too much trouble with it - I only had trouble when migrating to it), that might be the best option for you.
Standard Emacs is incomprehensible to me. I can't get what sick mind desided on the keyboard short cuts.
The same sick mind that used to spend a lot of time working with Symbolics LISP machines. Look up the "space cadet" keyboard sometime.
The tutorial really tries to get you to ignore the special keys on your keyboard. Page Up/Down, the arrow keys, Home, and End all work fine in Emacs, but the tutorial will have you doing C-v, C-n, etc. That makes sense if you're working with antique terminals. It doesn't make much sense today. Except for the glaringly obvious cut-and-paste commands, for normal use it acts more or less like any "normal" text editor.
There is some semblance of sense in the default keybindings. C-x is full of (usually) global functions. C-c is for mode-specific keybindings. Very common things have their own single combination keybindings (movement, saving, cut/paste, etc.). There's also some really confusing ones that require you to understand how Emacs works (like C-u for "prefix argument" that does different things to different commands). And of course, C-g, which stops Emacs from doing whatever it's doing to piss you off at the moment.
Honestly, I don't bother with most of the Emacs keybindings. I've memorized the ones I need (like C-c C-e l o to export an org-mode document to pdf) and use the vim equivalents for regular editing. I've got evil-leader installed, which will let me bind functions to the comma (as in, ",e" to export to pdf), but I never get around to actually setting it up.
2K was the future of Windows. Microsoft was attempting to move everyone from the old 9x architecture to NT. Yes, it uses different drivers (it's a different operating system altogether, just with some compatability stuff and the Win32 API), but your average user didn't know that. Microsoft went to great pains to make the transition between 9x and NT as transparent as possible.
ATI effectively abandoned the product when they didn't write drivers for it. That decision had consequences - one of which was losing me as a customer.
I didn't think of trying a driver for just one of the chips. Nothing showed up in any of my searches talking about that. Of course, that was fifteen years ago, so I don't remember everything I tried.
It's not the reason I don't buy AMD cards. It's not even the same company making them. But since I don't use them myself, I only have the word of other people to go on, and I haven't heard very many people saying good things about AMD video.
It still does. That's why it orbits instead of just floating in one spot.
Yeah, I had a Rage Fury MAXX (or something like that) that only had Windows drivers for 98.
Didn't matter on Linux, but I had some work to do on IIS for work and installed W2K Server on a second drive and set up dual boot. It gave me 640x480, 16 colors.
Their excuse: it's a gaming card, and people only game on Windows 98.
It really didn't matter that much to me from a practical standpoint - my home machine was Linux-only most of the time. But I decided since ATI wanted to dictate what their users could use their products for, I didn't need ATI.
Blender now supports OpenCL on AMD cards, so I could theoretically switch now, but I never hear good things about AMD. I'll stick with NVidia.
Yes. Look here. The README file gives instructions for converting the qemu/kvm images to virtualbox images.
It's not updated to the latest, though. Last update was in March of this year.
Get on a GNU mailing list sometime. It will open your eyes.
A lot of trolls on here call the GNU guys fanatics. This is one of the rare cases where they're right.
I have a lot of respect for RMS and the GNU people for sticking to their guns and pushing for free software, but yeah, they're kinda nuts.
Last time I checked (admittedly, years ago), the problem was that no one works on HURD. I don't know why. I think they had four people working on it sporadically when they did the 0.4 release.
It's not as if the basic concepts won't work, especially with fast machines like we have today. It's not even as if HURD is trying some new, revolutionary design - microkernel architectures have been implemented before (MINIX is a good example here). But for some reason, HURD just doesn't draw in the developers. And while a lot of code from Linux drivers would work in HURD drivers, there would still have to be significant work on each one - and that's assuming the basic infrastructure for what the driver does even exists.
It might be different now. I certainly hope so.
Will we see a future open source release of HP-UX, perhaps?
Doubtful. It'd take a team of software experts and lawyers a lot of time to verify HP's ownership of any source code that was released.
Sure, Sun did it with Solaris, but Sun has always been a lot friendlier with open source than HP and already had some large open source products out there (Java, for instance, and OpenOffice).
I haven't done a lot of work with HP-UX - just some support stuff. Is there anything there that's worth bothering with?
Emacs and vi are mostly useful to people who have to edit a lot of text. If you're only editing occasionally, or you usually use a "normal" editor, you'll never learn them.
I learned vi because I was a sysadmin and worked with UNIX all day. Every UNIX machine has vi, and it used to be common for it to be the only visual editor on the system (especially if you were working with commercial UNIX like HP-UX or Solaris, like I was). I would never have put in the time to learn it otherwise - I was happily editing files with pico before I learned vi.
I only learned emacs because of vi - I needed something with the power of an IDE, a good macro or scripting system, and vi keybindings (my fingers have hit the escape key three times so far while editing this comment - it's burned into my brain). Editing text was the primary part of my job. Emacs with evil-mode does that for me. Of course, I had to learn elisp, but I'll take that over vimscript any day. I find I actually enjoy the language.
The point is not that the public should embrace the use of drugs but that the war on drugs is a complete failure and actually doing harm.
It only makes sense that you should try something else when what you're doing isn't working.
Yep. Unfortunately, there's a lot more to it.
First off, there are of course the people who benefit from the current system. The criminal justice system is huge, and there are a lot of people and companies that suck on that teat.
Second, decriminalization is "soft on crime." That's political suicide in many parts of the country.
Third, a lot of conservative types support the war on drugs and long prison sentences. Those play well with the Republican base.
Also:
For example, we could legalize marijuana and decriminalize other drugs and use the income from taxes on marijuana to fund education to prevent abuse and social programs to help abusers get back on their feet and be proud of themselves and break their addiction (and, possibly more importantly, their need for their addiction.)
Ideally we'd try lots of different methods of helping people and use studies to see which methods are actually effective and worth continued funding.
You used the words "social programs." It doesn't matter how it's funded, it'll be classified as "socialism." Most Americans have a dim idea of what socialism actually is, but they know they hate it. Once the s-bomb is dropped, you've lost a lot of support.
I don't have any ideas for what to do about drug dealers who can no longer make a profit selling drugs, though. It'd suck to collapse that economy and drive them to a worse crime.
I don't know much about the larger drug network, but I do know a few small time dealers. The ones that don't already have regular jobs would probably just join the regular workforce. That's completely anecdotal, though.
And honestly, we already tax alcohol and tobacco and I have to wonder where all of that money is going.
I'm willing to bet it goes in the general fund.
I'm just hoping for a permanent base.
We went to the moon, then stopped, and haven't left LEO since. It's been forty-six years. We're currently incapable of going to the moon, because we lack the infrastructure and experience necessary. If we'd established an actual permanent base, we would have had reason to keep going. We'd probably have had feet on Mars already.
Don't get me wrong - I'm a big fan of the rovers - but you're just not going to get the scientific data and technological development that you would get if people were there on a permanent basis. Mars is harder to colonize, though, since it's has a higher gravity and is in a different solar orbit. If we had the experience of a permanent moon base, we might be able to pull if off.
It's user-level code I was thinking of. A lot of problems people are talking about aren't kernel-level, but related to bugs in the system libraries or applications.
If applications used TAI for time and converted only for output, many of these problems would go away, or at least change "bug that crashes the server" into "bug that prints occasional wrong time value on reports." The latter is a lot more visible and would be easier to troubleshoot and get fixed.
Databases are an example here: if databases used TAI instead of UTC for time values, it would eliminate a lot of the problems other people have been talking about in this discussion.
Regarding Macs: I remember Steve Jobs saying at some point that Macs were Y2K compliant and had been from the start. Given that early Macs weren't 32 bit (and with classic MacOS not having any UNIX heritage), I wouldn't be surprised at all to find they use a formatted time. I'd be very surprised if OSX didn't use UNIX time at the core, though - having formatted time in a low-level library (for compatibility with classic apps) makes sense, though. But this is all speculation on my part.
Ever heard that saying, "Emacs is a great OS but it lacks a decent text editor?" Well, thanks to evil-mode, now it has one.
I haven't seen much argument about evil-mode vs vanilla emacs. I think the consensus is pretty much, "it's all emacs." Emacs users generally customize their keybindings anyway - evil-mode is just a bit more extreme than most.
As for me, I like vim. I instinctively use vi keys when editing. However, I need custom scripts for some of the work I do, and I hate vimscript. Emacs gives me an editor that uses vi keys but lets me do customizations in elisp. It also has some other kick ass features I've come to like (org-mode is amazing). I still use vim for quick editing and sysadmin type stuff, but I write code and documents in emacs.
I'm sure it's better (I didn't use emacs before packages), but going from vanilla emacs to working IDE still takes a quite a bit of research and work.
Company or ac? Ido or Helm? Built-in CEDET, development version of CEDET (hope you don't do scheme development, 'cause semantic shits on it), or clang-based autocomplete? CEDET project management or projectile? Don't forget flymake - oops, that's outdated, now use flycheck, but wait, that's not compatible with...
Emacs is great, but for someone like OP who is used to "install xcode and run with it," roll-your-own probably isn't the way to go. That's why I mentioned spacemacs.
Well, yeah, the PDP-11 was 16 bits. The terminals weren't, though.
Given that vi was developed on a PDP-11, I'll grant you the point.
I can't comment on Atom (or Xcode, for that matter).
I can comment on UNIX-based editors and IDEs, though.
There's Eclipse's C/C++ module. It runs fine on Linux.
Emacs might suit your needs as well, but getting it set up with all the bells and whistles of an IDE is a bit of a pain. There are projects that help with that, however, like spacemacs (defaults to vi keybindings, but supports emacs keybindings as well). I use emacs with a custom config, but I haven't done much C++ since I switched from vim. What I have done has worked OK, but I'm sure my config has room for improvement.
QT Creator is cross platform and supports C++. It can do non-QT projects just fine.
There's Anjuta and KDevelop as well, but I haven't used either of those in quite some time and have no idea what the status is. KDevelop used to be used quite a bit for KDE development, which is C++.
What does "16 bit" have to do with terminals?
It looks like a javascript emacs. Anyone know how it compares in "hackability?" Are there github sites full of javascript mods for it like the elisp ones for emacs?
I'm not a fan of javascript, but I can see this being handy for someone who is.
Why should machines use UTC at all?
We have a time standard that doesn't use leap seconds - Atomic Time (TAI). We can convert between the two fairly easily.
So why not instead push for software to use TAI in place of UTC, and then convert for output or whatever? We could just have leap seconds in our time zone files and forget about the machine actually experiencing 23:59:60 at all.
Leap seconds correct for the Earth's rotation, not its revolution around the sun.
It's not that we'd see snow in July, but that we'd see sun at midnight.
No, I got it from my last job, actually.
It was "cheaper" if all our service area was in Tulsa, so that's where our service area was. That's about a two hour drive from where my company was based.
There are doctors here that accept that network, we just couldn't use them. My sister has the same insurance provider and has access to local doctors.
I've talked to people in other jobs who have had similar arrangements. Some are lucky, and are given the choice to pay extra for local service. Some, like me, didn't have that option.
I could have changed jobs, if I was willing to relocate or change careers. Having to change careers or move because you need better health care is not a point in favor of our current system.
That's funny, I know a lot of Americans that have gotten shitty and incompetent health care, misdiagnoses, and poor coverage. As long as we're throwing around anecdotes, I know one guy that was forced to turn down a good job offer because their insurance wouldn't cover his cancer meds. I also know a woman who only stays with her abusive cheating husband because she can't afford insurance for her Crohn's disease.
I never understand arguments like yours. Our health care system sucks. It's just as prone to poor care as any other system. It reduces freedom of the individual (unless you count corporate "individuals," where it adds one more control over their employees). It's expensive, it doesn't cover everyone, and we all end up picking up the tab for the uninsured anyway. It ties health care to employment, which is ridiculous - people making close to minimum wage can't afford it without subsidies, and if you lose your job, you lose your insurance. And the insurance companies will do everything they can to discourage you from going to the doctor in the first place; that's what the deductible is for, as well as the common practice of having all the "in network" doctors based in another city.
No system is perfect, but ours is just downright bad. You want to say the Canadian system sucks, go ahead - but don't pretend that ours is great.
Sure you can. Japan did it in 1945, and South Korea did in the 50s.
The marketing campaign to get Vietnam to outsource theirs failed, though.
I agree with you for the most part. However, while we might have solved the problem of "getting to the moon," we've never solved the problem of "staying on the moon," which is a different thing completely.
The hard part isn't getting people there. We can do that with today's technology - not cheaply, but we can do it. The hard part is keeping them alive on a world with a hostile environment that lacks many of the basic requirements for life.
Both a moon base mission or a Mars mission would require putting people in a completely closed self-sustaining environment (while we could resupply a moon base a lot easier than a Mars base, it's not economical to do so, and they would need to be able to survive if a shipment or two was missed). Either mission would place humans in a high radiation, low pressure, cold environment. Either mission would place humans in a low gravity situation for extended periods. All in all, we'd face tougher challenges on the moon, but we'd have a better chance to respond in emergencies. Considering the bad PR NASA would get if they lost a crew, that last bit is important.
That said, I don't propose changing focus at this stage of the game, simply because constantly changing objectives is a recipe for accomplishing nothing. The above arguments apply the other direction as well, so technology developed creating a Mars base will help with developing a moon base.