I believe that's 400 people who told Peter that they would be possibly interested in contributing something back when he first floated the idea. I was one of those 400, but when the time came I didn't have a subject lined up that I felt was suitable for the format. I think that's why starting something like this is much harder than sustaining it. In the next year I might come up with two or three things suitable for the journal and put them aside until I have time to develop them into an article, but coming up with something to fit a deadline is much more difficult. Coming up with a topic for an inaugural issue that will presumably set the tone for the publication is even more daunting.
Hail, god amongst men. Once upon a time I thought I was a very good C programmer. Today I know myself to be a terrible programmer. I surround myself with safety mechanisms such as -Wall -Wextra -Werror and the clang analyzer, but even these tools cannot stop me from shooting myself in the foot time and time again. Please enlighten me, such that I may learn to write safe code in an unsafe language infallibly.
The only effective safety mechanism for C code is size. You must treat everything you write in C as though it's a tiny standalone library, and then build your application from those libraries. "Frameworks" do not work here. (Unless, that is, you're going to go insane and implement a refcounting gc and double-indirection pointers, like C++ programmers do. That works, but at that point, you've lost all speed and simplicity benefits and you might as well just use your favorite Java substitute instead. Remember: you write C because you want other stuff to use it. When you implement your own memory model and semantics, you lose that. And then you have if statements, integers, goto, and segfaults.)
Oh! It's so easy. I can't believe I didn't think to do that before.
... but every time I do find a bug, I am surprised to find it. Thus it stands to reason there are bugs I have not yet found. How do I find all of them?
Ah, well you seemed most concerned about the sheer quantity of foot-shot-off type bugs you put in, so I thought I'd put your mind at rest about that first. Sadly, that part is inevitable.
As for finding them before anybody else does, I suggest all of the following, which is what I do, because I've found it to work for me:
* Never run outside debugger unless you have previously verified inside the debugger that the run will work - this ensures that you are in a position to fully investigate any problems that might occur. (Some programs can't be verified ahead of time, because they're non-deterministic. (Hopefully due to non-deterministic sources of input, rather than anything in the code!) You just never run these outside the debugger.)
* Never run optimised build if you can help it (this is what the QA department and your users are for :) - again, this ensures you are in a good position to investigate any issues you discover. (Note - you should feel confident about using the debugger with an optimised build, most likely using the disassembly view, but I figure life is too short to be doing this all the time.)
* assert, lots, about everything, particularly pointers into buffers and indexes into arrays.
* -Wall, -W4, -Whatever
* Investigate memory manager's maximally-anally-retentive mode. If it doesn't have one, find a memory manager that does, and use that one instead. Switch it on and fix every complaint it might have.
* Find every debug option and #define for every library you use, and switch all of them on.
* Try to avoid having any multithreading.
* Make sure you know as many dark corners of the language as possible, and commit them to memory, so that you'll be able to spot them when people start making use of them accidentally.
* Add in some kind of crash dump/stack trace/etc. display to your program, so if it should crash during actual use then you stand some chance of getting some useful information back. (Avoid frame pointer omission for this reason.)
Unfortunately I can't guarantee that this will necessarily work, but I've found the above to at least have helped me minimise the sort of creepy, freakish bugs that you only get in C and its ilk.
Do you have a piece of code you feel confident about, such that you'd be able to say "here is an existence proof of carefully-written resilient C code of some significant length"? I'd like to take you up on an offer to validate that proof.
I do, but it's unfortunately internal at work. Everything I write for fun has so many library dependencies that you just have to cross your fingers and hope that it will all work as documented :)
To say that wingo has forgotten that systems software needs to be written is both insulting and flat-out wrong. He is a language implementor (Guile). Of course he knows that it is still needed and what it is needed for.
tl;dr: don't believe it, at least not for any recent Intel ThinkPads.
I have the ThinkPad T420 with Sandy Bridge graphics that they list as "Certified" under 11.04. This is at best highly misleading. I bought this laptop under the delusion that choosing components that were supported by open source in-tree drivers written by the actual hardware vendor was the right decision to make. Alas, Natty out of the box hangs quite frequently, and X is very unstable. The DisplayPort output is unusable, and even non-DisplayPort output via an adapter didn't quite work.
After quite a lot of fiddling, I've found that the latest upstream kernels (I'm using 3.1-RC9 at the moment) from the Kernel PPA mostly fix the hanging, and using KDE with the XRender compositing backend addresses the rest of the issues I have. OpenGL stability is still a disaster, but I don't really have any need it for anything. I'm not sure if native DisplayPort actually works yet; I got a small HDMI adapter to use instead. Using XFCE would probably work just as well, but don't expect stability from Compiz.
Oh, and if you use dm-crypt (which you should on a laptop) you'll get a stupid error from Grub on every boot unless you uncomment GRUB_TERMINAL=console in /etc/default/grub (&& run update-grub). For reference: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/699802
tl;dr: don't believe it, at least not for any recent Intel ThinkPads.
Counterpoint: I chose the ThinkPad X220 because it was on that list and it works (nearly) flawlessly under Linux. The only problem I know of is that the mic mute button doesn't work. That's it.
Which distribution of Linux? Do you use compositing? If so, what compositing window manager are you using? What's your typical uptime? Do you use multi-monitor? Have you used an 802.11n AP, particularly a 5GHz AP supporting WLAN power save (such as an AirPort Extreme)?
Under a different set of circumstances, Natty could have been said to be flawless on my T420, and indeed I thought it was for the first few days. When I started using the system more intensively for the tasks I bought it for, I began to notice the problems.
- Distro: Ubuntu, then Fedora
- Compositing: Yes
- WM: Mutter
- Uptime: weeks, currently 15 days
- Multi-monitor: haven't yet, I could try and let you know what happens
- 802.11n: No
I noticed on the notes for your laptop that you have an Nvidia graphics card. I had an Nvidia on my last laptop and that experience convinced me never to get a card that requires a proprietary driver. I always had issues with compositing, resuming from sleep, and artifacts appearing on my desktop (especially text corruption in terminals).
Unless you were naive enough to buy the X220 with the "Thinkpad b/g/n"[1] wireless option. Then, grief, anger, acceptance/resignation (in the form of a USB wireless stick[2]).
There is a host of other issues, but nothing that can't be worked around after hours of researching blog posts and manuals. More kernel panics on suspend (related to the aforementioned USB wireless), external monitor issues, USB 3 port disappearing ... You know, small stuff.
[1] RTL8188CE 802.11b/g/n WiFi Adapter (in my case, anyway)
I'm a 2011 MacBook Pro (8,1) owner who, due to some lapse of rational thinking, bought the laptop with the intent of running Linux on it from the get-go.
tl;dr -- Natty was a horrible experience for Sandy Bridge systems, but Oneiric has been much, much better.
I think this was the case for all SB systems during the Natty cycle. When SB dropped in the beginning of this year, the Intel code throughout the kernel (graphics, as well as general processor stuff) was pretty bad. I had a lot of lock-ups and freezes with those kernels back in the Natty beta (I got my MBP in early April, IIRC). Even after upgrading to the bleeding edge kernel (to get extmon support with integrated graphics), things were still pretty ugly (the biggest insult was the wireless card not working).
Suffice to say: I ran back to OSX screaming like a big, first-world-problem-having baby.
So, I labored until the hateful gaze of Cupertino for those six months (my work is done in a Windows VM so the host system doesn't matter, beyond what "makes me happy".. pleasure coding happened in an Ubuntu VM running awesome-wm). When Oneiric came around, I decided to give it another try and, I'm happy to say, they finally got their shit together. Anecdotally, I haven't had a single lock-up. I've gotten wireless working (was a bit of an effort and I have to rebuild kernel drivers whenever the update manager installs a new kernel) and the remaining issues are pretty minor: inferior battery life (paradoxically with better resource usage for my workflow), sub-optimal resolution on monitors, OSX vs Linux trackpad drivers, etc. But, overall, I'm much happier that I was able to stick it out (I was this close to offloading the machine on craigslist).
How are dual booting your MBP, with Bootcamp, or some other way? I've been thinking about doing that too but it's hard to find good info on how feasible it is.
I use rEFIt[0]. It's somewhat customizable/themable (you can change the icons, default partition, etc), but is otherwise nothing special/flashy. I've never used bootcamp, so I can't really do a feature comparison between the two. It gets the job done.
Oh, and I forgot that I had to disable powersave for the iwlagn driver in order to get any kind of performance out of it. I'm using the Intel 6300AGN; I tried to buy a 6200AGN from Amazon to try it out but Lenovo locks their BIOS to specific PCI product IDs.
If by any chance anyone else needs this, I just put a small shell script that runs "iwconfig wlan0 power off" in /etc/pm/power.d/wireless . The name is important because it overrides another script elsewhere with the same name.
There are probably other things I configured or changed that I can't recall right now. I need Linux to get my job done, but I'd be using VMware under Windows if I could get away with it. (For various hardware-development reasons I can't.) It really wasn't worth my time to figure all this out.
"Also, I think the parent post was referring to the fact that Steve Jobs is now CEO of Apple which IIRC does most of their manufacturing overseas (SE Asia)."
Does Apple have any manufacturing operations currently? I would be surprised if they did.
"And the US can still complete as both a low-cost and a world-class manufacturer."
Assuming that you're referring to the type of electronics manufacturing that NeXT was doing at its plant, can you provide any evidence to support this assertion?
Most of that is almost certainly, in part, for tax related reasons. Intel is profitable; profitable US companies want to keep those profits outside the US (see: Google).
I'm assuming that you have relatively recent experience in order to make this kind of statement. If you are happy with the cost, quality, capability and flexibility of your US-based contract manufacturing solution, please name names as there are many people who would be interested.
Hidden features in a programming language? Granted, most of these aren't "hidden", but they're nonobvious because the language is incredibly complex and it's difficult to predict from first principles that any of these things would actually work.
Long ago, a rule of programming language design was handed down by the great old hackers, but it has been forgotten and much needless effort has been spent as a result. It's time to remind language designers of the rule again:
"Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary."
Some of those features are just some fancy libraries, or syntactic sugar that you can ignore, if you want to. They don't make the language itself more complicated.
Yes, and some of those `hidden features' are just nice library functions that avoid adding features to the core language. Look at `enumerate' and `zip' for example, which allow Python to get away with one very simple for-loop.
I think Guido is well aware of that rule, and makes a conscious effort not to add unnecessary features to the language. Still, there's no way you can maintain any non-trivial piece of software for 20 years and not have a few unexpected "features" come up.
Beyond the flood of SEO spam and Demand Media-style content mills, there's another search quality problem I have with Google: torrent sites. I will frequently search on the exact name of a song or album on Google in order to find out more information about that song or album, but lately most of the results have been links to torrents, including results on the first page. This applies even if I add "review" to the search query. I will even see links to torrents ranking above links to iTunes.
These songs and albums are not available legitimately through torrents. What value is there in providing links to pirated content? I understand that Google is not under any legal obligation to remove these results, but as a non-pirate these results are significantly lowering my perception of the quality of Google's search results.
This is HN, so I'll give an example related to my startup. We make a wireless (802.11g) flash drive called the AirStash, which works like an ordinary USB SD card reader on a PC and uses HTML5 for the interface on wireless devices. Here's an example of spam content from eHow that talks about our product:
"Wireless flash drives communicate with wireless devices using wireless protocols."
You don't say?
"Advanced wireless flash drives stream data to more than one device at a time."
Well, we're the only one out there, so I guess they're all advanced!
"Insert the USB portion of your wireless flash drive into an available USB port on your computer. Your computer should automatically recognize the device. If not, click the "Start" button and then click "My Computer." Double click the flash drive in the removable media section. This opens the drive and displays the files. Double click the executable file (start.exe, for example) to start the installation process."
Uh, no. No software installation is ever required, a point we make abundantly clear on our web site.
