OpenBSD 6.7 - <AUTHOR> https://marc.info/?l=openbsd-announce&m=158989783626149&w=2 <comment><USER2> That's an impressive changelog. I'm excited about the new ARM SBC drivers and seemingly improved RPKI flow for OpenBGPd. I should try running a toy route server on an RPi4 with OpenBSD/OpenBGPd, or a full DFZ router.

</comment><comment><USER3> Here's the download page and poster. [https://www.openbsd.org/67.html](https://www.openbsd.org/67.html)

</comment><comment><USER4> Looks like a great release, thank you.

OpenBSD is one of the last really good choices for an operating system, in my opinion. Redhat, the pretentious gnome developers, canonicals latest folly, proliferation of systemd cancer (homed being the latest abomination)... All these things take away from the user's freedom.

I hope OpenBSD continues for decades to come.

</comment><comment><USER5> Thank you! I installed OpenBSD again this year after I rage-quit Ubuntu. It is a delightfully clean OS where the important things just work.

Highly recommended for everyone to try out.

<comment><USER6> I have a co-worker who describe OpenBSD as: "The least stupid operation system you can install".

<comment><USER7> Just curious, did he really say "operation system" or was that a typo/auto correct thing in your post?

I ask because I had a coworker/friend years ago from Ukraine and that's what he called it. My other friend and I who worked with him could not get him to say operating system no matter how much we poked at him. Anyway, just like the article itself you brought back a flood of memories so just curious like I said.

</comment></comment></comment><comment><USER8> I've played with OpenBSD on a VM a couple times and really liked it, but I'd like to use it on real hardware and try and force myself to use it as my main personal system at least for a while as an experiment.

I've often heard that Thinkpads make great OpenBSD laptops. Are there any models in particular the HN crowd would recommend? In terms of my hardware needs, I don't really care about graphics like you'd get with an Nvidia card, but I do need wi-fi since it'd be really hard to set up a wired connection to my router in my current apartment.

<comment><USER7> I've had great luck with T-series ThinkPads. I'm using a T520 as a daily driver at the moment and I've had no real issues with it. I installed it on an E series laptop a while ago and had issues with sound (this was a few versions ago, probably 6.3, and I was just playing around at the time so I never figured out what the problem was).

Mind you I use this mainly for work so my needs are simple, an editor, a browser, a compiler and the like. The default window manager cwm makes for a simple "desktop" for me and the only thing I use at the moment for work that's not from base is mariadb, vim and firefox (plus dependencies of course). So I don't have a lot of splashy graphics to load or anything like that and don't do video or image editing very often. But even if you do need more, the package repository has a huge selection of programs and in my experience they all just work when installed.

On the other hand I put Battle for Wesnoth on it and although that's not really a very graphics intense game it runs great on the laptop.

Overall I really like using it day to day.

<comment><USER9> > _The default window manager cwm_

Just a slight correction, if you meant the "default" as in the window manager that starts on a freshly installed system: It's not cwm but fvwm. With that said, OpenBSD ships with cwm and it's trivial to switch between the two, but they are very different.

<comment><USER7> Oh, you're right, I'd forgotten that. I think it's so ingrained in me to copy my dotfiles to a new machine before I do much else that I don't usually ever see fvwm. I always add myself to doas, move some public keys around, install a few packages and then copy my dotfiles before I ever launch X for the first time.

And yes, they are very different. I remember using fvwm fondly on Slackware Linux back in the mid 90's. I had hours of fun trying to configure it to look like Windows 95 and populating menus, all in a plain text file, no gui config available! I think I read somewhere recently that fvwm is still Theo's preferred WM and that's why it's the default...

<comment><USER9> > _I remember using fvwm fondly on Slackware Linux back in the mid 90 's._

Same, well late 90s here, and yep that was my go-to on Slackware, mostly because it was quite usable out of the box. I eventually went to Blackbox, then Fluxbox, then Gnome about six months before Pat decided to stop shipping it. I went to Xfce from there and never looked back (I never liked KDE before Plasma, and 4.x is still the default in Slackware).

</comment></comment></comment></comment></comment><comment><USER10> Yesterday, out of sheer coincidence, I thought, you know what "lets check out OpenBSD again". Went to the homepage, saw the last 6.6 release was 6 months ago, and thought Hmm thats kinda old. Trawled around on the mirror sites to download it, and found version 6.7 files were there - a full day early! Not even timezones could explain it. Release date: May 19. So I downloaded it.

I made my first router with OpenBSD back in 2001, for a job, it was great! But I got fired for it, because the boss didn't understand how to use a command line...

I really love the OpenBSD documentation myself though. And how the whole system is made a way that they want you to understand what its doing. And a certain nostalgia over all the familiar components that still feel the same. Its like a time machine. I was transported to the year 2001 when I made that first router all over again, or earlier. It has that familiar smell to it. Like a grandma cooking with the same recipe for 25 years. Initial Version 1.1 = 18 October 1995

Now I'm going to investigate using OpenBSD as a GUI desktop, but I have concerns about Xenocara/X11/Xorg/Xfree86, (idk what to call it) being insecure: root perms, keyloggers, etc. Can anyone speak on that ? Has OpenBSD been fixed itself, or is it still using the same flawed codebase. Are there plans to move to Wayland?

<comment><USER11> > Are there plans to move to Wayland?

As far as I know, the difficulty on OpenBSD would be input. The Wayland world relies on evdev, so they either have to patch it to use their interfaces, or implement evdev.

On FreeBSD, we have a lot of devices supporting evdev :) Including the next generation HID stack: [https://github.com/wulf7/iichid](https://github.com/wulf7/iichid) (currently external, but would be merged into the system eventually)

Also there's device discovery, for which we use [https://github.com/FreeBSDDesktop/libudev- devd](https://github.com/FreeBSDDesktop/libudev-devd) to pretend to be udev, but I suspect the OpenBSD people might not like solutions like that :D (Actually, does OpenBSD even have anything devd-like that provides hotplug notifications?)

<comment><USER10> Very helpful thank you. I believe you are correct on all fronts. Does anyone know if "their interfaces" prevent the Xorg/Xinput keylogger "bug" as is, even without EVdev or Udev? The man page seems like it does use Xinput, but it also mentions Xwayland [https://man.openbsd.org/xinput.1](https://man.openbsd.org/xinput.1) So I think that if Wayland does work, that interface would take care of the issue. I am in the middle of something else or I would try and figure it out myself, but it would take a long time.

<comment><USER11> No, the "xorg keylogger" issue has nothing to do with the low level stuff (evdev is how the windowing system gets info _from the kernel_ , udev is how the windowing system enumerates devices and gets hotplug notifications). The "xorg keylogger" issue is a fundamental property of _the X11 protocol_ , it's between the server and clients — all clients get enormous amounts of access to all kinds of global state over the X11 socket.

</comment></comment></comment></comment><comment><USER12> Will OpenBSD 6.5 from this day no longer receive security patches?

<comment><USER2> Yes. Only the two most recent OpenBSD releases receive security and reliability fixes for the base system. [1]

[1] - [https://www.openbsd.org/faq/faq5.html#Flavors](https://www.openbsd.org/faq/faq5.html#Flavors)

</comment></comment><comment><USER13> If you like the OpenBSD artwork poster - you can support future OpenBSD artists through the merch shop at [https://openbsdstore.com/](https://openbsdstore.com/)

<comment><USER14> Just another OpenBSD developer chiming in that this is the official store link; profits from the sales go towards paying artists for the next release.

The artwork for 6.7 was done by Jonni Phillips!

</comment></comment><comment><USER15> I just upgraded. What is this 'dt'? The mail linked here says there should be a bt(5), but [https://www.openbsd.org/67.html](https://www.openbsd.org/67.html) says dt(5). In either case neither exists on my new 6.7 system. Nor does btrace(5), which dt(4) references.

<comment><USER16> The phrasing is a little odd but only the driver dt(4) is part of the 6.7 release. The language bt(5) and userland tool btrace(8), whilst in tree, are not part of this release. The following mailing list posts give an introduction to these components.

[https://marc.info/?l=openbsd- tech&m=157920008000433&w=2](https://marc.info/?l=openbsd- tech&m=157920008000433&w=2)

[https://marc.info/?l=openbsd- tech&m=157920081500935&w=2](https://marc.info/?l=openbsd- tech&m=157920081500935&w=2)

</comment></comment><comment><USER17> Does anyone know if IPsec IKEv2 daemon can send multiple certificates (chain)? I tried to setup IPsec VPN with Letsencrypt certificate, but ultimately failed, because OpenBSD only sent leaf certificate and Windows failed to recognize it without intermediate. It works for me with strongswan in Linux.

<comment><USER18> havent tried this - but is your iked(8) cert file the full chain or just the leaf?

if just leaf, maybe try with full?

also haven't tried, but looks like the built in acme-client(1) can be configured to save the full chain if you're using that for the cert issuing stuff (acme-client.conf(5))

<comment><USER17> Yes, I tried different variations and even tried to dig into sources, it seemed at that moment, that it only sends a single certificate. That was 2-3 years ago, I think, so may be that changed.

</comment></comment></comment><comment><USER19> If you have already 6.6, you can upgrade by running:

        doas sysupgrade

It is uncanny how well this works. I've never had an ubuntu upgrade work as seamlessly.

</comment><comment><USER20> I miss not having new release songs.

<comment><USER13> if you want to record one for the project, let me know! :)

</comment></comment><comment><USER21> prgmr.com has updated it's openbsd installer version to 6.7.

We were a bit surprised to see "Fixed softraid(4) CRYPTO volumes on 4K-sector disks" in the release notes. We don't have any 4k logical sector drives but for some reason I thought that was reasonably common in consumer drives these days.

</comment><comment><USER22> Probably opening Pandora's box here, but I've been wondering for a long time: why do people still use BSD? If memory serves me right, the *BSDs descend from the original Berkeley Unix from the 70s - but why stick to that "line of descent" rather than going with the newer, Linux, line?

<comment><USER23> Why did Apple choose BSD and not Linux?

Why did Netflix choose BSD and not Linux?

Licensing is often a factor.

The reasons however will not be the same for everyone.

There are more similarities than differences between the two, however one difference IMO is that BSD has a level of "quality control", especially over the userland, that Linux does not. I find that my own sensibilities as a user align better with the relatively small number of people doing "quality control" and development for BSD projects than with the enormous number of people who work on Linux -- for me, the number of Linux contributors is too many to keep track of and I find it difficult to understand what all of their sensibilities are.

<comment><USER24> Whatsapp chose BSD too

<comment><USER23> Good example. There are so many, not all of them are made public.

</comment></comment></comment></comment><comment><USER25> Where can I find a recent unbiased analysis of OpenBSD vs Debian security?

<comment><USER2> Here's a recent talk evaluating OpenBSD's security mitigations: [https://www.youtube.com/watch?v=3E9ga- CylWQ](https://www.youtube.com/watch?v=3E9ga-CylWQ)

The objectivity of it is up to debate though, some argue that it is biased/unfair.

<comment><USER25> Thanks!

</comment></comment></comment><comment><USER26> How does security of OpenBSD compare to modern hardened cloud OS kernels?

<comment><USER27> What is a "modern hardened cloud OS kernel"?

<comment><USER28> It's an operating system kernel that can apparently provoke a response from a number of people in spite of having two buzzwords prefacing it.

</comment></comment></comment><comment><USER29> Why provide that antique gcc? Better to not provide gcc at all, and an ability to install a recent GCC at user's discretion, than to provide a 12 year old gcc in the base system.

Why is their clang/llvm stale in a new release?

<comment><USER30> _Provide_ isn't the the right word. GCC is in the base system because some architectures haven't yet switched to clang, either because clang doesn't support the architecture, or because the work of switching the toolchain (which is not trivial) has not been done yet. The system must be able to build itself, so "better to not provide gcc at all" doesn't make sense.

In the cases where OpenBSD (and FreeBSD) don't yet use clang, they use the most recent GCC version that was still GPLv2 licensed. GPLv3 is not acceptable to OpenBSD in the base system.

More recent versions of GCC are _provided_ in the ports system, for users to install. Those are not used by the base system. The system compilers are (mostly) for building the system. They don't even search in regular paths users might expect, like /usr/local. If users need a general purpose compiler, they can install one from ports.

The situation with clang is similar. OpenBSD uses the last version of clang/LLVM that was still BSD-licensed. Now LLVM uses the Apache license, which is not acceptable to OpenBSD in the base system. (However, FreeBSD is okay with it.)

<comment><USER10> How is the user supposed to navigate all the logistics and technical ramafications of ethical/political dev / package choices ? Everything has alternative versions, its hard for me to keep track of who forked what and why.

<comment><USER31> Generally speaking they don't need to. If you are developing C code and need some particular compiler version, you just install a package (ie "pkg install gcc9") and make sure to set CC=gcc9, and that's it.</comment></comment></comment></comment>


Phonebloks - <AUTHOR> http://phonebloks.com/ <comment><USER2> There are numerous threads on Reddit that explain very well why this concept is not really feasible [1,2,many]

The (imho) most important ones in short:

* Mechanical modularity increases size and cost, makes it harder to create a beautiful phone, and is not in the manufacturer's commercial interests. Therefore, it would be hard to find companies/customers to build/buy this.

* Many current components are highly integrated - SoCs, sensor ICs, Display/Touchscreen, etc. Making these modular would require development of many new components (and would increase size, cost, power consumption).

* The concept assumes that all components use a common communication backplane. This is not feasible, as a variety of voltages and communication protocols are in use in a typical phone (I2C, SPI, UART, USB, various display protocols, etc.). Many components need very short connections to the CPU/GPU/whatever without crossing other PCB traces. It is not really feasible to make this work with a generic communication backplane. Proper heat dissipation for CPU/GPU is another problem.

In summary, while it is certainly feasible to build a modular phone (look at David Mellis' DIY cellphone [3]), doing so for current hardware would involve _major_ engineering effort (== design and manufacture dozens of new chips) and would result in less stable, more expensive, and less beautiful phones requiring more power.

Nevertheless, such ideas are certainly helpful to catalyze thoughts about future hardware.

[1] [http://www.reddit.com/r/gadgets/comments/1m6y1q/that_phonebl...](http://www.reddit.com/r/gadgets/comments/1m6y1q/that_phonebloks_things_annoyed_me_so_here_are_17/)

[2] [http://www.reddit.com/r/explainlikeimfive/comments/1m4pmy/el...](http://www.reddit.com/r/explainlikeimfive/comments/1m4pmy/eli5_why_is_phonebloks_a_bad_idea/)

[many] [http://www.reddit.com/r/all/search?q=phonebloks&restrict_sr=...](http://www.reddit.com/r/all/search?q=phonebloks&restrict_sr=on)

[3] [http://hlt.media.mit.edu/?p=2182](http://hlt.media.mit.edu/?p=2182)

</comment><comment><USER3> While this is obviously very far from feasible, what _is_ possible is a return to servicability for the two parts that most commonly fail: batteries and screens. The rest of the phone is usually fine unless subjected to serious physical battering. The legendarily reliable Nokia 3210 is your landmark here.

Note that in a modern phone, the screen strength usually is achieved by bonding it to the case, so in practice "replace screen" turns into "take mainboard out of case and place in new case".

Modularity doesn't really help at all with the constant drive to replace working phones with newer, better ones. But there should be an effective secondhand market selling them to the Third world - and there is! No shortage of websites offering people money for their old phones.

Long term, we have to wait for the Moore's law slowdown, and a rise in Chinese manufacturing wages and other costs, before a local western repair industry becomes viable again.

(Apart from all the other issues, phonebloks would turn "Android fragmentation" into a far more extreme version; you can't guarantee that your peripheral will even be there next time you turn the phone on).

<comment><USER4> There should also be a better way to return phones for recycling. Mining the gold and minerals is destructive and it's weird to me that it's easier and cheaper to dig up ore and process it than to grind up old tech and process that.

<comment><USER3> In Europe, the manufacturer is _legally required_ to either accept old devices for recycling or contribute to a shared fund for doing this. (The program is called "WEEE": [http://www.environment- agency.gov.uk/business/topics/waste/1...](http://www.environment- agency.gov.uk/business/topics/waste/139283.aspx) )

<comment><USER5> Which is an enormous racket and close to impossible to comply with economically for small manufacturers in some countries.

As an example, in Germany, if you are a small electronics manufacturer and sign up to the system, you get entered into a lottery weighted by the amount of devices (measured by weight) you ship, and whenever a container of e-waste gets filled, a randomly selected unlucky participant has to take possession of said container, no matter where it happens to be or what it's full of, and find some way to dispose of it. It's absolutely insane. In addition, you have to pay a fee to get to participate, and also you are subject to random inspections by an entity with absolutely no oversight that is legally prevented from having competitors. You have to pay for the inspections yourself too, to the same entity, which also runs said lottery.

There's no option to only accept your own devices for recycling, and also no option to contribute to a shared fund that takes care of it all. There's a small industry that will sell you INSURANCE against winning the shit lottery.

<comment><USER3> I hadn't realised it was quite that crazy.

I'm still wrestling with CE approval for a device containing a GSM module. Which looks like it's going to be about E15000 for the radio and electrical testing, plus the complexities of RoHS compliance (random lab testing required, even if all your components are certified lead-free?)

I've concluded that Tindie-style electronics cottage industry is basically illegal in the EU. Fortunately I can still buy stuff from dealextreme and alibaba that doesn't have to comply..

<comment><USER5> With a GSM module, you want a pre-approved module so you only need to do EMC testing. Doing your own radio testing is ridiculous and expensive. For RoHS compliance you should be able to get away with a declaration as long as not only the components but also the assembly process is lead-free. Incidentally, I have some thoughts on fixing this process, if you'd be willing to talk about it. Contact me on IRC (Kliment on the freenode network) or at kliment at 0xfb.com (yes, that is a zero)

</comment></comment></comment></comment></comment></comment><comment><USER6> With everyone pointing out it's infeasibility in mind; didn't Bug Labs do something similar already?: [http://buglabs.net/products/blocks](http://buglabs.net/products/blocks)

<comment><USER7> And how's that working out? It's feasible, yes, but not in the consumer market. Bug Labs is for prototyping.

</comment></comment><comment><USER8> It immediately reminded me of this [http://dansdata.blogsome.com/2008/03/03/stop-press-pixie- dus...](http://dansdata.blogsome.com/2008/03/03/stop-press-pixie-dust- unsuitable-for-household-lighting/)

It's cool on paper, as long as you don't think about the technical implications. I guess it's a good project marketing-wise.

EDIT: this page is more comprehensive: [http://dansdata.blogsome.com/2007/04/24/break-the-laws-o- phy...](http://dansdata.blogsome.com/2007/04/24/break-the-laws-o-physics-win- a-prize/)

</comment><comment><USER9> This looks like a marketing stunt:

* the site does not have anything on it besides a video and an Amazon widget (go for the quick bucks?)

* it is not a real site, but a campaign on thunderclap.it (a new kind of service and really interesting concept )

* the video promotes an idea that you can have a good looking phone which you can customize however you want - who wouldn't want that?

* they let the impression that it's only the petty, nasty corporations that don't want such a phone to exist, just to be able to upsell us more phones and rip off our hard earned money, totally not addressing the technical issues.

What could happen (it already did) - the video and the campaign went viral, so:

* the authors of the campaign get a few thousands of dollars from the Amazon referral commissions

* people hear and see the power of crowdspeaking platforms in action (thunderclap.it)

</comment><comment><USER10> as poorly thought out as this looks, what I wouldn't give for a smart phone with a very low resolution e-ink swapped in screen plus the opportunity to replace all the camerawork,sensors, storage , etc with more battery. At least this may get someone thinking about the idea.

also the video and concepts kept making me think of how hot a big metallic "speed block" would be against my hand

<comment><USER11> E-ink has too many problems, and it's not very good for anything other than mostly static content. If you're thinking "like Pebble" \- Pebble doesn't use e-ink. It's using a type of LCD similar to PixelQi.

Mirasol on the other hand, has a ton of potential, and it seems to improve the overall battery life of a device by at least 3x (which means the display itself should be many times more efficient than LCD). Too bad nobody has picked up yet (other than Qualcomm themselves [1]) to use it into a line of products, so we can see improvements done faster to it (such as to color accuracy, gamut, contrast, animation speed, etc).

[1] [http://www.androidpolice.com/2013/09/07/ifa-2013-hands-on- wi...](http://www.androidpolice.com/2013/09/07/ifa-2013-hands-on-with-the- qualcomm-toq-smartwatch-video/)

<comment><USER12> Despite the disadvantages, I would really like an e-ink phone (and netbook) for the significant increase in battery life it could give. The software could be designed so that it is usable on e-ink. No animations, no reliance on color for indicators, flipping instead of scrolling, etc. As you say, it would only really work for static content, but for me that is fine.

<comment><USER13> Almost any phone not a smartphone could fit your description. There are so many phones that can last for almost a week, but all you can do is talk and text with some light apps.

<comment><USER14> Do you know of one with a QWERTY keyboard?

<comment><USER15> The Blackberry 8800 fits this description.

</comment></comment></comment></comment></comment></comment><comment><USER3> Relatedly, the Fairphone is shipping now: [http://www.fairphone.com/](http://www.fairphone.com/)

"Fair" in the sense of "ethically sourced tantalum, etc"; but they've also thought about e-waste and deliberately included a replaceable battery.

</comment><comment><USER16> People don't bother upgrading their PC boxes so why would they care about updating part of their phone ?

<comment><USER17> You don't know too many gamers, do you?

</comment></comment><comment><USER18> Remember when desktop PC where made from interchangeable components? How many people actually upgraded them instead of buying a new, boxed one?

<comment><USER19> A lot of people did and still do. And that was actually quite 'hard' because you had to touch micro electronics. If you make PCs (phones, laptops) out of Lego, people will do it much faster and more often. Going to a gig? Pull out the bluetooth, plug in the midi block. Going on the road in 2 countries? Pull an USB block, plug in a second 4G. Etc.

Edit; not saying this is a good idea for a phone, but to some extend it would be for a laptop (not ultrabook). Some rugged ones are quite like that.

<comment><USER3> Or buy the integrated phone that includes all of those features and doesn't make you swap them out and risk losing or damaging the blocks.

Modularity often ends up being a _cost_ to the unsophisticated majority of end users. People don't like it in their software (preferring a "complete solution"), nor in their hardware (e.g. cheap integrated hifi versus expensive minority separates).

<comment><USER19> But these kind of things are thought up by a minority of technically minded people who;

\- like to change/tinker with their hardware \- like to change/tinker with their software \- like products which do one thing and do it well

</comment></comment></comment></comment><comment><USER20> Instead of trying to make improvements to Apple's (or whoever's) stuff, let's stimulate consumer demand for great looking _enclosures_ for (small form factor) hardware. There should be a market for enclosures that look as good as Apple's (or whoever's). Note I said "as good as" not "just like".

Give consumers the option to mix and match enclosures with the cheap electronics that go inside and see what happens.

The growing market for RaspberryPi enclosures stands as proof that it is possible to have many different enclosures, made by third parties, for the same PCB. And that consumers will buy them.

I've long wondered why there should not be a wide variety of enclosures to choose from for various popular small form factor "development" boards. Would such enclosures sell? Why not? The growing number of third party Pi cases being sold is testing that assumption.

I'd even go so far as to guess that if you give consumers great looking enclosures to choose from, you will actually sell more development boards.

</comment><comment><USER21> Some issues I notice:

1\. Blocks are having different sizes. Sure you may have some fillers, but they don't look nice. A light drop could shatter the whole thing (phone must be able to take hits and drops for many reasons)

2\. The pluggable architecture calls for the backbone to be some sort of shared bus, example will be I2C, which may not be efficient for high-bandwidth transfer (e.g. camera to memory). A dedicated bus for some modules will just break the 'plugability'. Mitigation could be to zone the backbone so that each zone's traffic is limited, well, that is not simple...

<comment><USER22> My concerns were similar.

What bus can be used which will be fast enough for all of the components to work together? Sticking a cpu, camera, memory, and screen on the same bus will cause an amazing bottleneck.

How will the components be made to fit in the same thickness? Can you really fit a higher resolution camera in a larger (but not thicker) package?

In that regard, what's to stop someone from making an uber battery which only takes up a few slots but then covers the previous layer on the back, thereby increasing the real estate?

How much force can those pins hold?

Will the bins be biased in some way such that the positive will be every N pins and negative every M pins, and data lines every L pins or something? If so, will the holes be keyed to ensure proper placement?

There are a lot of questions to be answered before this thing can come to fruition, and I think the bus is going to be the biggest limitation. There's a reason this phone doesn't exist yet, as I'm sure hardware manufacturers would love to continue selling people hardware over and over, but there's a genuine problem with bandwidth in this setup where anything can go anywhere.

A better solution would be universal plugs/ports with specific uses for each port. Battery port, CPU port, memory port, and then accessory ports, just like a modern desktop. This would allow the components with the largest bottlenecks to have their own dedicated bus.

</comment></comment><comment><USER23> This is a pretty naive idea. There are a lot of reasons to go in the opposite direction

For example, water-resistant phones are going to be hard to take apart, and that's a feature that will result in many fewer dead phones.

Packaging for mobile handsets is continuing to evolve. Any modular system would be obsolete long before it breaks even on repairability, upgradeability, etc.

</comment><comment><USER24> I think this idea is brilliant. I may be in the minority but I think this would be a great thing for young kids to teach them how components can be swapped out very easily. I would get one of these for my 10 year just to watch him figure out what he'd like to add or upgrade.

</comment><comment><USER25> In order to reduce electronics waste, we should recycle what's already there. Not invent a new phone that's easier to recycle. Also, people will want to upgrade or change their phone configuration even when it's not broken. I don't understand why the video is pitching the product as if its sustainable and fighting waste. It's not.

</comment><comment><USER26> Relevant discussion on reddit: [http://www.reddit.com/r/electronics/comments/1m4m0f/this_is_...](http://www.reddit.com/r/electronics/comments/1m4m0f/this_is_currently_on_the_front_page_a_good/)

My opinion is that this wasn't thoroughly thought through...

</comment><comment><USER27> I completely understand the appeal of the concept, but it seems like it would be significantly more expensive for the same features of another phone. I'd be concentrating on the features that most frequently drive upgrades other than the screen: memory and camera.

<comment><USER28> But then you also need to include those features that most frequently crap out: screen, battery (easy enough), jacks (maybe a block of jacks -- power, microusb, headphones?).

Otherwise you'll be upgrading memory and camera on a broken phone.

It's a wonderful concept, but extraordinarily hard to pull off. I'm glad he's trying to find partners before any thought of crowdsourcing.

<comment><USER27> Why would you -have- to? I've never broken any of those things personally, other than the typical battery charge degradation. If the camera+battery+memory are modules, it may be cheaper just to replace/tradein the main body over doing a repair.

Handwavy on the costs, but modular is definitely more expensive - being able to trick out your phone with bigger memory and large-aparture camera may be worth it to a certain set of customers.

Agree it's a wonderful but hard to implement concept.

</comment></comment></comment><comment><USER29> Site is currently down, here is their video on YouTube:

[http://www.youtube.com/watch?v=oDAw7vW7H0c](http://www.youtube.com/watch?v=oDAw7vW7H0c)

</comment><comment><USER30> This site has been down for days at the exact time the video is going viral. There is another site [1] www.phoneblocs.com that has more information

<comment><USER31> The guy keeps posting this, but it's a fake scam site with ads asking for bitcoins. Which, as he said, he is not taking donations: [https://twitter.com/davehakkens/status/378204427363946497](https://twitter.com/davehakkens/status/378204427363946497)

</comment></comment><comment><USER32> Hmm. Would you buy phone components from people who can't do Unicode? "It�s pretty cool." Revenge of the SmartQuote.

<comment><USER33> They're not selling it themselves, just proposing the concept.

</comment></comment><comment><USER30> [http://www.phoneblocs.com](http://www.phoneblocs.com) is up and has a copy of the video.

</comment><comment><USER34> My biggest gripe with this is, what problem does this actually solve?

Phones exist as they are as a sealed unit, so if something fails or you want something new, you buy it from the manufacturer or network.

Networks or manufacturers wouldn't want this kind of thing because it would affect their profits, so what's in it for them? What solution is it offering them?

That's before we even get into the engineering flaws...

<comment><USER35> Well standards and replaceable parts brought the PC to world domination.

And the networks should be removed from the device business at all.

So a smartphone that could be assembled and upgraded with full control and root access is idea that I stand behind. And if it forces the carries to compete on services and not lock people with contracts all the better.

<comment><USER36> Standards _cheap_ replaceable parts brought the PC to dominate their very expensive IBM counterpart.

See the problem, is that this idea, with today's technology would be more expensive to build than the device it is competing against. (if it was possible at all)

And if you need to go against the network too, it means competing against $200 iPhone5s and the like.

</comment></comment></comment><comment><USER37> Nice idea. But I simply fail to see how this could make something more than another geek toy.

<comment><USER35> I have said the exact same quote for the iPhone. And have heard it about the Raspberry Pi. Probably someone somewhere in the early 80s have said it about the IBM-PC. Geek toys have the power to change the world when the brain behind them leverages them to new and amazing things.

</comment></comment><comment><USER38> one alternative would be to have a phone with a cpu that can be desoldered and replaced easily and in a more voluminous case (maybe a nice cnc milled alumin(i)um case)

<comment><USER39> "Desoldered and replaced easily"? Clearly, you've never actually desoldered anything. :) It's a tricky process which requires a good deal of special- purpose equipment and training, and even with that, there's a nontrivial chance that you'll damage the part, the board, or both in the process. It's _not_ something you'd ever want to do on end-user equipment.

</comment></comment><comment><USER40> Lots of people seem to agree this concept is appealing indeed, but physically impossible.

<comment><USER41> Physically impossible? I've seen crazier things happen.

</comment></comment><comment><USER42> Please stop. It' so painful to see this link here after reddit.

</comment><comment><USER43> Schei� encoding

</comment><comment><USER44> Wasn't the Moto X supposed to be super configurable like this? It got me excited from the rumors and the hype. At the end it turned out to be just some colors that can be picked.

[http://www.talkandroid.com/154586-rumor-upcoming- motorola-x-...](http://www.talkandroid.com/154586-rumor-upcoming-motorola-x- is-not-just-one-phone-but-a-new-line-of-devices/)

> And finally— the mysterious device(s) will be completely customizable by > allowing the device's color, RAM and internal storage to be completely > configurable.</comment>


iPhone Naysayers - <AUTHOR> http://techpinions.com/iphone-naysayers/10198

<comment><USER2> On issues where there's a large contingent of passionate haters/supporters on either side, polarizing articles from either extreme drive page views. It's just business.

It gets old though. I've come to realize over the past few years that the stuff I spend my time reading on Hacker News does take it's toll in mental and emotional energy. Often a lot more than I realized. If there's anything I wish I could filter from my media intake, it would be _both_ iPhone Naysayer articles and responses to iPhone Naysayer articles such as Jim's here.

<comment><USER3> This is an excellent point. It's amazing how worked up we ("we" the General Public) get over "platform wars" -- I remember arguing Super Nintendo over Genesis back in the day, and iPhone v. Android is just another iteration of that.

Bottom line, it's your money, buy what you want and what makes you happy.

<comment><USER4> Console wars are far from over, and they are still duking it out whether or not PC gaming is "dead".

Best to have friends who have the competing technologies to what you have so you get to enjoy _all_ of it.</comment></comment></comment>


Learning Programming with Nim - <AUTHOR> https://narimiran.github.io/nim-basics/ <comment><USER3> I've got a systems level project I want to play around with, however GC is not a deal breaker for me. The languages I've been considering are Rust, Nim, Crystal, and Zig. I've started writing it in Rust but the syntax is unnecessarily noisy for my taste and there are too many times I have to do similar things in a slightly different syntactic way due to some inherent idiosyncrasies, which makes the code much harder to read. In addition, it seems like there are often too many ways to do the same thing, which increases the surface area of the language.

I like Nim syntax the best, and Crystal and Zim are tied for second. I don't mind a small library / ecosystem. The main things I'm interested in are:

\- I want to write once and run on Windows / Linux / Mac. (I'm not writing a GUI.) \- Concurrency and async capabilities \- Safety guarantees (both types and threads) \- Speed

I'd be interested in people's recommendations, or links to comparisons between these languages.

<comment><AUTHOR> I have spent time learning, messing around with, and evaluating each of the languages that you have listed. In the end, I decided to go with Rust for my particular application, which is a large (100k SLOC) GIS application. Rust and Zig are probably the fastest of the listed languages, although Nim and Crystal are not far behind. I found Nim to be the easiest to program in, despite my lack of Python background. The friction factor seems the lowest. Crystal is quite a nice language, but I have reservations about its future, which have been shared by its originator (the compiler may not scale well), and it does not have Windows support or support for multi-threading. If these obstacles are overcome, it could be really interesting. Nim is really great, but they have to hit v1.0 by the end of year. I'm not sure if the devs realize how important this is to the user community. Zig is quite interesting, and highly performant, but it is probably at the earliest stage of the listed languages. Rust is certainly the furthest along in development, has a larger user community and learning resources. It's not the easiest language to learn or use. I agree with your assessment of the language but will say that things get much easier once you've spent some time with Rust.

The other languages that you didn't mention but are worth evaluating are D and Go. Again, they have advantages and disadvantages that may make them either more or less suited to your application.

<comment><USER4> > they have advantages and disadvantages

D only has advantages.

<comment><USER5> This is just more propaganda from Mr so called 'Bright'.

Sure some things in D are 'interesting', but it's also a very, very complex beast, full of bugs (some known, and heaps more not-known).

btw. Do not participate on the D forums either, it's just a propoganda tool for the D Foundation (i.e. they filter (or moderate as they like to call it), anything that says anything negative about d.

In the end, if D has anything interesting, that we can't live without, we can just take it and integrate it one or the many 'proper' programming languages.

Don't waste your time with d. You'll only ever end up wishing you had spent that time on a proper language, that has a well supported ecosphere.

<comment><USER6> I don't know about the moderation stuff, but yes, from what I have read, D is very very complex.

Also it seems to have a multiple personality disorder.

Mr Bright seemingly wants it to be the next C.

Mr Andrescu seemingly wants it to be the worlds best meta template programming language.

D users are equally split (is it a better C#, a better Python, a better this, a better that??).

It does seem to be very complex, undisciplined vision for a language that aims for mainstream use.

Then you have all the problems with the lack of library support for this or that, lack of support tools for this or that ...etc etc.

If you read the forums, people spend far too much time debugging their code, due to a variety of strange things that occur in the language due to all its different personalities trying to live in the same place.

So don't be decieved - there really are plenty of disadvantages in using D (and perhaps they outweigh the advantages).

<comment><USER7> Did you try to use it?

I did, not very intensively for now, but the general feeling has been good:

\- I can use it from day one if I know C++, something to consider if you want to get things done

\- it interoperates better than other languages with my C++ stuff

\- the metaprogramming capabilities are nice and familiar to someone coming from C++

\- the standard library is well prepared and the ranges, algorithms, named tuples and others are well-thought designs that have zero overhead (they use compile-time mechanisms for algorithm selection or tuple code generation)

\- std.experimental.allocator: you can control memory management, though I did not use this myself and I do not know how mature it is

\- there are efforts to make the language more gc-free friendly if that is what you need

\- there is a switch for betterC that allows you to use a subset that is powerful yet still very light

\- compile times are good

Is it complex? Well, it can get as complex as you want, but using it without being too fancy is joyful and easier than C++, definitely. I have been investigating several of these languages for a while, concretely, a bit closer Nim, Go and D.

Go is very nice at what it does, but that's it. It can be written and used in teams easily, but it is too specialized: by specialized I mean you have the GC with the channels and goroutines systems but you do not have control on memory layout or indirection or allocation AFAIK. Interoperability is also more difficult than with D.

Nim looks promising. The problem is that it looks promising, but the reality is that it is not ready for production use yet. Also, something that should look like an advantage looks like a disadvantage to me: it looks clean because it follows a Python syntax. D chose to follow C and C++. That is an advantage, no matter how clean Nim looks, because at the end, most people know C. The library ecosystem is far better in D also. Interoperability: I think Nim is easy to mix with C, but not with C++ and Objective-C. Do you really know of anyone that would adopt a language without a realistic migration path of their code bases? Maybe for hobby projects yes, but for enterprise? Because these things can get painful easily and they make for a lot of time wasted.

D: powerful and understandable metaprogramming if you come from C++ (I saw Nim's metaprogramming and I must say it also impressed me, that is true). Good migration path. More mature than Nim. General purpose, can control memory allocation. Trying to solve real world problems. The most pragmatic tool for general purpose programming if you want good performance and getting things done, something I care a lot, because at the end the language is just a tool. I do not need a perfect tool, I need something convenient that lets me finish things.

From this pack, for me, D is the only one that is a positioned candidate to be both general purpose and mature enough at this moment. Nim is not there yet, unfortunately, and interoperability and lack of maturity play against it strongly. If you add that almost anyone knows C and many people know C++, but many people will just not know Python, that is something else to consider. As for Go, it is too specialized in one area, which does very well. But it is what it is.

<comment><USER6> Yes, I spent 6mths with it.

As with any programming langauge, if you do simple things, and do them often, then you'll probably have little to worry about. D certainly makes many things simple for you.

On the otherhand, the language has no personality that you get your head around. It tries to be everything to everyone.

If you are presented with some code for D app, it's not possible to understand what 'style' programming you'll see, until you see it - because the language supports so many paradigms.

Although, not all paradigms are faithfully represented.

For example, class-oriented programmers will get at least an intial shock, when they realise that private class members are public witin a module. Any code in a module can change any part of your encapsulated classes.

Then, you have the issue of public being the default.

Then, you have the issue of class instances being able to share mutable data.

And the list goes on..and on... and on..

If you've never programmed before, these might not be such a big deal, but if you're an experience programmers from a mainstream langauges, you'll spend a large amount of your time working out all these things for yourself, most of the time.

I personally do not see the benefit for experienced programmers to switch from a well supported, well maintained, mainstream langauges, to D. It just does not make sense to me.

Sure D does some interesting things. Other languages can learn and take from D, just as D has taken so much from other langauges.

In the end, there is nothing in D that really changes the nature of programming. It's all the stuff we already know, all wound up into one big monstrosity, that lacks any real supporting ecosphere.

<comment><USER7> > On the otherhand, the language has no personality that you get your head > around

I do not get this point. I use D as a C++ improvement (which is what it was since the beginning) and I can do from functional, to OOP to structured or generic programming. No personality? You mean it does not favor any paradigm? That is another of the reasons why I chose it. By this measure, Nim is another non-personality language: the package offers the same things -> soft real-time gc, generic, structured and OOP (with Nim Style programming), metaprogramming. Should I say that Nim has no personality and conclude it is not useful? Nim is not useful due to "metaproblems" -> tools, maturity, worse interoperability than D. I do not say the language is not nice, I just say that it is more complicated to get things done with it from a perspective of someone looking for something that can work. Also, following Python makes it for very nice- looking code, but I am not sure it was the right decision from a social point of view (more people know C/C++ than know Python).

> For example, class-oriented programmers will get at least an intial shock, > when they realise that private class members are public witin a module

I consider that a design mistake, but that does not preclude powerful metaprogramming or superior interoperability, which are far more important to my use case.

> Then, you have the issue of class instances being able to share mutable > data.

I make primarily use of structs and all gc stuff and mutability problems disappear.

> I personally do not see the benefit for experienced programmers to switch > from a well supported, well maintained, mainstream langauges, to D

The case for C++ is still very strong for me. But try to get good compile times and do something along the lines of static if (I do not mean only if constexpr in C++ with templates, try to avoid macros for config if you want and you will see, or add a conditional member to a class, or simulate something like version, or generate code without messing with macros)

> In the end, there is nothing in D that really changes the nature of > programming.

That is a fair opinion, but I can say that in D there are these small nice things that I value in day-to-day programming like static if (a powerful one, not one that is in the middle between useful and full-featured), overloading opDispatch for forwarding, fast compile times and a module system. The faster compile-times are really, really something that makes more of an impact, maybe, than everything else.

I understand your point, D has nothing "revolutionary". D is not revolution, it is evolution. But D is targeted at doing and using techniques that have been useful for years (and not experimental) easier and convenient: from memory allocation control to gc-free programming, immutability or _better interoperability_ (something that should not be underestimated when using older code bases). I really think that people that see nothing "new" in D should try and see how the full package works together. They will be surprised. And they will also be surprised at how much of the older techniques, in improved versions, they can use. Techniques that have been useful for decades, not experiments of the last FP trends or experiments for which drawbacks are not well known.

I used to think things along the lines you say. I still use C++ mainly, but, when I have another chance, I will insist on D a bit more. I think it is worth the time.

> It's all the stuff we already know, all wound up into one big monstrosity, > that lacks any real supporting ecosphere.

That is precisely the strong point of it. It is evolution, not revolution. Did anyone discover lately a better general programming paradigm suddenly that makes all the other obsolete? Not AFAIK. Packaging things in familiar ways has real advantages of lowering the learning curve or figuring out more easily how to interoperate with older code bases. As I said before, that should not be underestimated if you really want to get things done and deliver stuff. If you are just toying around maybe you enjoy more something more revolutionary. But if I have to get things finished, I would bet on D rather than Nim or Go for most use cases.

<comment><USER8> You keep repeating the line that D is far more interoperable than Nim. Did you miss my reply below? Or did you simply not believe me and downvote it?

Once again. Nim is superior to D in terms of interoperability with C, C++, and Objective C because Nim can compile to either of those languages. For C++ interoperability this is a huge benefit.

I'd love to hear why you disagree if you do disagree. Otherwise please give Nim a try and stop spreading this as a disadvantage of Nim.

<comment><USER7> > You keep repeating the line that D is far more interoperable than Nim. Did > you miss my reply below? Or did you simply not believe me and downvote it?

I did not downvote anyone unless it was an accident :)

> Nim is superior to D in terms of interoperability with C, C++, and Objective > C because Nim can compile to either of those languages.

I did not try myself. Well, I did not try Nim to the level I tried D, starting bc I know C++ better than D, though I also know quite a bit of Python (my "second" language).

I have a question, though, about interoperability: you can output Nim code to C++, and mix it. Fair point. But that would be useful to integrate my Nim code into C++ (C++ being the "driver" app). What about the other direction where I can consume C++ from Nim? I have no idea and I ask this question with the best of the intentions :) You thought very bad about me and the downvotes before.

<comment><USER8> > I have a question, though, about interoperability: you can output Nim code > to C++, and mix it. Fair point. But that would be useful to integrate my Nim > code into C++ (C++ being the "driver" app). What about the other direction > where I can consume C++ from Nim? I have no idea and I ask this question > with the best of the intentions :)

I was actually talking about it from that direction, i.e. using C++ libraries in Nim. You can wrap pretty much any C++ feature in Nim: destructors, namespaces, you name it. Because Nim compiles to C++ it can interface with it incredibly well.

Happy to answer any more questions in case I'm not clear.

> You thought very bad about me and the downvotes before.

Apologies. I just saw you reiterating the line I challenged without replying to me and was wondering what happened. Was just asking, not blaming :)

<comment><USER7> Yes, I am genuinely interested. So I am going to ask a bit more. I am open to new and better tools :)

> I was actually talking about it from that direction, i.e. using C++ > libraries in Nim. You can wrap pretty much any C++ feature in Nim: > destructors, namespaces, you name it.

Is there any documentation about how to wrap my C++ code into Nim? I do get I can generate C++ from Nim, but I am not sure how it would look to use C++ from Nim. In D for me it is quite clear (with extern (C++) and there is a clear mapping for interfaces and other things. I do not need anything spectacularly fancy, just smooth. Y' know, I am a person who likes to finish things without getting too lost on the details.

You also mentioned many people consider Nim "production-ready". My question here is, if I start to try it, how many breakages can I expect? 4-5, in the tens? Until version 1.0 I mean.

And my last question: how does it compare to D if I have to:

\- use a well-mantained GUI library in at least one system (multiplatform would be a big plus)

\- how mature is the standard (and other libraries also if that is easy to add) library for: json handling, binary serialization, algorithmic code (a la range-v3 or ranges in D. Something along the lines of python iterators, functools, comprehensions and itertools also ok).

\- would I be able to use Nim in embedded if I do a port of some software? Namely, would I be able to remove the GC?

One thing that worries me is that I am much more familiar with metaprogramming in C++ and D's metaprogramming is much closer than Nim's I guess. If you could refer me to good (as in up-to-date) Nim style I would highly appreciate it, specially in the areas of how to manage runtime polymorphism and metaprogramming with an eye on generative programming (basically I want to generate a bunch of things from 3 or 4 basic building blocks in arbitrary combinations).

Thanks for your time!

> Apologies. I just saw you reiterating the line I challenged without replying > to me and was wondering what happened. Was just asking, not blaming :)

No problem, I just did not mean to make anyone offended :)

<comment><USER8> > Is there any documentation about how to wrap my C++ code into Nim?

Here is some docs: [https://nim-lang.org/docs/manual.html#implementation- specifi...](https://nim-lang.org/docs/manual.html#implementation-specific- pragmas-importcpp-pragma)

> My question here is, if I start to try it, how many breakages can I expect? > 4-5, in the tens? Until version 1.0 I mean.

Depends which features you are using. The newer features (concepts for example) will likely have more breakages than the rest of the language. We already have a lot of code written in Nim and a book published (which we are committed to keep compatible with 1.0) so breakages should be minimal (unforeseen circumstances of course may happen).

> how does it compare to D if I have to: > > \- use a well-mantained GUI > library in at least one system (multiplatform would be a big plus)

I'm not sure about the status of GUI support for D. Nim has bindings to GTK/QML/libui and some other more experimental GUIs rendered using pure OpenGL (nimx). They are all cross-platform (although GTK on macOS is a PITA).

> \- how mature is the standard (and other libraries also if that is easy to > add) library for: json handling, binary serialization, algorithmic code (a > la range-v3 or ranges in D. Something along the lines of python iterators, > functools, comprehensions and itertools also ok).

JSON handling is very mature.

I don't think we have binary serialisation in the stdlib.

Algorithmic code - sequtils is what you're after I guess: [http://nim- lang.org/docs/sequtils.html](http://nim-lang.org/docs/sequtils.html)

> \- would I be able to use Nim in embedded if I do a port of some software? > Namely, would I be able to remove the GC?

Sure, but you won't be able to use a lot of the stdlib.

> One thing that worries me is that I am much more familiar with > metaprogramming in C++ and D's metaprogramming

I suppose Nim by Example is a good place to look, it has some good metaprogramming examples: [https://nim-by-example.github.io/](https://nim-by- example.github.io/)

Also my book has a chapter on metaprogramming :) [https://book.picheta.me/](https://book.picheta.me/)

Hope that answers your questions!

<comment><USER7> I must say that, even if unfamiliar to me, I am quite impressed about the C++ interoperability :)

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Author of the tutorial here.

I didn't expect that somebody else might post a link to it - it seems I might be too late for the party.

If anybody has any questions regarding Nim or suggestions how to make the tutorial better - let me know.

<comment><USER10> If I may be so bold as to comment on form rather than function, I wanted to say I am not particularly fond of the typography / design choices for the tutorial.

I know this is dangerously close to bikeshedding territory, but if I may, I wanted to point you to a similar resource that I recall being particularly pleasing to read way back when I was getting started in Python / Django:

[https://web.archive.org/web/20080730140551/http://www.django...](https://web.archive.org/web/20080730140551/http://www.djangobook.com:80/en/1.0/chapter09/)

That content has been retired from djangobook.com, and the website's design has followed suit, hence the archive.org link. I suggest also perusing the table of contents and making note of small design hints such as the use of color, whitespace, "Note" callouts, etc.

At the very least, I hope you'll find this inspirational if you decide to take a moment to rethink typography, typesetting and the overall design of the website and PDF.

<comment><USER9> > _I hope you 'll find this inspirational if you decide to take a moment to > rethink typography, typesetting and the overall design of the website and > PDF._

Thanks for the feedback!

I would very much like to improve the looks of the website and PDF.

The current situation is this: I have _zero_ experience with html/css, so I just took some css template and tweaked some values (lots of trial and error) until it looked okayish (There is probably some unneeded stuff in there too). And PDF is created by using the default style of asciidoc-pdf - I guess this can also be customized, but haven't looked into it yet.

Having said that, if somebody with more web-experience would like to improve my style.css [0], PRs are welcome.

[0] [https://github.com/narimiran/nim- basics/blob/master/style.cs...](https://github.com/narimiran/nim- basics/blob/master/style.css)

</comment></comment></comment><comment><USER11> I'll take the chance of suggesting also Dominik's book (1) both because it's good and because so I can politely ask the publisher next time please do use bigger or darker fonts for code:) The print is perfect, but I'm a glass wearing old fart with some difficulties with thin fonts when they're not dark enough. As an example, I can read perfectly HN fonts though they appear even smaller than the book ones. The white paper background could also be a factor though, I in fact like a lot more non 100% white backgrounds.

(1) [https://www.manning.com/books/nim-in- action](https://www.manning.com/books/nim-in-action)

<comment><USER8> > I'll take the chance of suggesting also Dominik's book (1) both because it's > good

Thank you :)

> I can politely ask the publisher next time please do use bigger or darker > fonts for code

I think it's unlikely the publisher will see your message here. You might have better luck Tweeting at them or emailing them.

</comment></comment><comment><USER12> Looks like this time Nim is only receiving good comments and praises! It is very interesting and I've been following the language from some time already, since when it was still named "Nimrod".

In the past I already mentally classified it as a not very well defined language, with a not very well done feature set analysis. A comment in HN described it in a way that seems to fit: _(...) a hodgepodge of stuff thrown together, a lack of language design with a surplus of features_ (from this thread: [https://news.ycombinator.com/item?id=11960814](https://news.ycombinator.com/item?id=11960814))

It's not the only time when the language's (arguably) unnecessary breath has been critiziced: from having a _suprisingly huge feature set_ ([https://news.ycombinator.com/item?id=13312205](https://news.ycombinator.com/item?id=13312205)) to _implementing everything but the kitchen_ (sink) and having a _lack of engaged contributers, leading to many bugs, little documentation, and a very messy standard library_ ([https://news.ycombinator.com/item?id=13355579](https://news.ycombinator.com/item?id=13355579)).

Have those comments (which admittely only represent the personal opinions of their owners) been rendered outdated by now?

I'd argue that for an absolute zero-knowledge starting point, Rust would be more valuable to start learning, given that both would have a big (or "huge") surface but very different levels of apparent polish and structural design choices behind them. But of course, it's all a matter of taste.

</comment><comment><USER13> That is the clearest, most succinct explanation of variables, types and mutability I've ever read.

I'm not deep into this yet but I dig the 'voice' being used. It's difficult to break 'obvious' things down to those without background while staying concise.

<comment><USER9> > _That is the clearest, most succinct explanation of variables, types and > mutability I've ever read._

Thank you very much! It means a lot to see this kind of feedback.

> _It's difficult to break 'obvious' things down to those without background > while staying concise._

After writing this tutorial, I can only nod and agree with this statement - <USER2> took me much more time than I originally thought it would.

</comment></comment><comment><USER14> 'Nim in Action' from Manning is well written and solid, I found recently. Nim is surprisingly robust, I'd mention. The book has a chapter on using Jester for a web framework. This is adequate for some things. If anyone is at the point of using Nim as a server for React clients, doing something beyond a hello world (interacting with forms), I would love some pointers. I haven't yet thought through what may be done with Nim's capability to compile Nim code to javascript in situations like this.

<comment><USER8> You should check out the newly redesigned NimForum[1][2]. It is written 100% in Nim using Jester and Karax (a Nim framework similar to React). Karax itself has a number of examples in its repo[3], we're also always happy to help you out if you want to pop into IRC or post questions on the forum :)

P.S. Thank you for the kind words about Nim in Action!

1 - [https://forum.nim-lang.org/](https://forum.nim-lang.org/)

2 - [https://github.com/nim-lang/nimforum](https://github.com/nim- lang/nimforum)

3 - [https://github.com/pragmagic/karax/tree/master/examples](https://github.com/pragmagic/karax/tree/master/examples)

<comment><USER3> Does Nim in Action still apply to Nim 0.18?

<comment><USER8> It does. It's our aim to keep all the examples working for the 1.0 release (some deprecation warnings may appear though).

</comment></comment></comment></comment><comment><USER15> Significant whitespace and case- and underscore insensitivity. That's pushing too many of my buttons for one language.

That being said, this is a very well written tutorial. Might be a nice format to use in other basic language tutorials.

<comment><USER16> it isn't entirely case insensitive, just to clarify.

<comment><USER17> If anything this clarification makes Nim seem _less_ appealing. I hope Nim has a _very_ good reason to make its case sensitivity "case-dependent", because it sounds quite confusing...

<comment><USER8> The first character of an identifier is case sensitive and by convention used to determine whether the identifier is a type or not.

As for style insensitivity: it allows you to keep your code base consistent. Ever had to use a library that used snake_case in your own camelCase codebase? Well, with Nim you can just use camelCase everywhere.

<comment><USER18> I also don't see the issue with it. You can have a uniform style in your project, regardless of dependencies you use. And what's the flipside? People want to use more than one identifier named the same thing only with different case?

Is that really desirable? I posit that if you have a codebase that breaks if fooBar and foobar refer to the same variable, it's already broken!

<comment><USER19> The flip side is one has to use a Nim-specific search tool to find occurrences of an identifier.

<comment><USER8> In practice you really don't. As kungtotte alluded to, no one is going to be mixing coding conventions inside a single code base. As soon as you see the first identifier is camelCase you can safely assume that the rest of them are also camelCase, and therefore search using camelCase.

<comment><USER20> I'd say that's only mostly true - if you had a typo, and wrote "camelcase" instead of "camelCase" in just one place out of a hundred, you might not notice it, but it will compile, and not match a grep (though it will match nimgrep). This case could be solved by "grep -i" or equivalent, but not the camelcase vs. camel_case case.

This is not criticism; I prefer Nim's mostly-case-and-underscore-insensitive approach, but I think this is a pitfall that should be acknowledged and taken into account (which is quite easy to do given the included nimgrep).

Perhaps it makes sense to have an optional warning in case a name is inconsistently spelled inside the same compilation unit.

<comment><USER21> > if you had a typo, and wrote "camelcase" instead of "camelCase" in just one > place out of a hundred

There are already formatter tools that check for that.

Also, any editor with completion will suggest the right form every time preventing the bug.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER22> I've been meaning to try this tutorial out on some non-programming friends of mine. But time is unfortunately a limited resource, so I haven't gotten around to it. I helped proof read the texts and clear up some stuff, so if you have any questions about it feel free to ask and I'll try to answer as much as I can! But it hasn't been "battle tested" yet and it might be updated should we find things people struggle with, both with Nim and programming in general.

</comment><comment><USER23> Anyone here qualified to compare Nim to the D programming language?

<comment><AUTHOR> There have been insightful comparisons in both communities:

Nim: [https://forum.nim-lang.org/t/1779](https://forum.nim-lang.org/t/1779)

D: [https://forum.dlang.org/thread/mailman.1427.1428691340.3111....](https://firstname.lastname@example.com)

And the following is probably one of the most extensive comparisons of the two languages: [https://github.com/timotheecour/D_vs_nim/](https://github.com/timotheecour/D_vs_nim/)

</comment></comment><comment><USER24> I used to get excited about new-language posts on here, but I've gotten weary of them over time. So many are just slight variations on standard syntaxes that meet their creator's preferences. It's rare to see anything that's radical, and therefore truly interesting.

<comment><USER25> Nim isn't a new language, it's been around a while.

<comment><USER26> There's something about not hitting 1.0. It instills doubt on adoption that things will change in a breaking way soon, and that you're going to need to rewrite your stuff in potentially non-trivial way.

I liked playing with Nim in spare time. But, I don't think I'll use it for anything I care about to maintain for a long time.

<comment><USER27> Every language has faced challenges with change, nothing specific to Nim. And 1.0 is a distraction, if the language version has all the features you want, you can use it as long as you want. The code is also open and an unbearable bug can be easily backported.

If you do want the new cooler features, then ya, you may need to port your code but that's the case with any compiler update - you need to run a full regression at the very least.

<comment><USER28> 1.0 _may be_ a distraction but I think it's a fair one. It's a common enough convention that pre-1.0 versions are the developer's way of saying, "please please please don't treat this as ready and production quality. We're still figuring some things out and haven't settled on some key choices."

If that's not what the developers are trying to communicate with a pre-1.0 version I do wonder what they're gating 1.0 on. What needs finalization? Documentation?

</comment></comment></comment></comment></comment><comment><USER29> Because this is about learning programming with a language, here is a shameless plug for learning with D: [http://ddili.org/ders/d.en/index.html](http://ddili.org/ders/d.en/index.html)

</comment><comment><USER30> >Nim is a statically typed programming language, meaning that the type of an assignment needs to be declared before using the value.

This is not strictly true, in languages with type inference (which are becoming increasingly common)

<comment><USER22> Nim has type inference as well, but the type still has to be known before we can use a value.

From the tutorial:

> Nim also has type inference ability — the compiler can automatically detect > the type of a name assignment from its value, without explicitly stating the > type.

<comment><USER23> Well that's exactly the point. It's statically typed, so of course types have to be known at compile-time, but it can use type inference rather than explicitly expressing type in declarations.

Static typing with type inference is still static typing.

Vaguely related: many people also confuse 'dynamically typed' and 'untyped', despite that they're not even close.

</comment></comment></comment><comment><USER25> I really like the look of Nim and would love to see it gain some traction. Just wish I had the time to play with it more.

</comment><comment> happy-go-lucky > Who is this for?

> People with minimal previous programming experience

> People with some programming experience in other programming languages

Both mean the same.</comment>


Rate/Review my startup - textbin - <AUTHOR> http://www.iode.co.uk/textbin/

<comment><USER2> I stared at the homepage for a couple of minutes and still couldn't figure out what it did. So I thought I'd try and create whatever a bin is and I'm asked to login. I stopped there.

<comment><AUTHOR> Ok, I've added a "What is textbin?" bin which briefly explains the idea. It needs work but it's a start!

This is a really simple idea and it's not really ready for release yet (which is why there is currently little explanation about what it is!).

I guess I am hoping the comments here will help me to decide whether this is a waste of time or not! I keep changing my mind myself so I thought I'd get some constructive criticism and see what happens!</comment></comment>


Ask HN: Advertising networks that pay per click, but are flexible. - <AUTHOR>

I'm having quite a bit of trouble finding pay per click ad networks that have the following criteria:
1. You can have complete control over which adverts you show and where. I don't want a network where I drop in some js and it analyzes my page, because that isn't appropriate for webapps. Ideally I just want an inventory of adverts that I can handle myself.
2. You can update links etc in realtime. (via DOM manipulation)
I'm really surprised google adsense doesn't have a product tailored to ajax type applications yet. For a webapp where you don't have any page reloads, the existing google adsense is pretty useless.
If anyone knows of any networks I'd be really grateful. (At the moment using cj,linkshare,clickxchange,and a few uk based ones, but these are mainly lead based). If I can't find one I'll probably end up making my own and having advertisers come direct etc, but this would be a bit of a diversion if there's already some out there. <comment><USER2> I have found that if you do your homework and use well targeted ads you will make much more using non-PPC advertising. edit: I was avoiding introducing too many new acronyms, but I was suggesting CPA

Let's say you use some sort of program and get paid per lead - I would suggest CJ/Linkshare/Neverblueads[1]. Then track the ads well, see which work and fit in with your site. Look for a clickthrough rate of at least 0.10% (although depending on how you display/cycle the ads this could be off). Then from there look to have a conversion rate of definitely better than 1/10, aim for about 1/3.

If you work in those numbers (probably your first attempt will be about half that), you will make more than PPC. You will also completely control how you serve ads and not be bound by the conditions of something like adsense.

I used to work for a major website, and they tended to make more per click on their ad campaigns that were revenue sharing than PPC as well.

Because of how behind the times the ad industry is in terms of AJAX sites, I really doubt you will find someone who allows you to change the ads in the method you desire.

[1]<http://www.neverblueads.com/signup?ref=aff_66639> if you want to signup (that would give me a referral). It is pretty highly rated.

<comment><USER3> I'd also recommend Google Affiliate Network (formerly Performics) if you're going to start serving CPA ads. We did an analysis of which of the "big three" to use (CJ/LS/GAN) when planning for the 4th quarter for Dawdle, and I'm scarily impressed by the investments Google is making in the platform.

<comment><USER4> Please excuse my ignorance, but what does GAN stand for?

CJ = commission junction, LS = linkshare, GAN = ?

<comment><USER5> Google Affiliate Network

</comment></comment></comment></comment><comment><USER6> Look at it from this angle: With ppc, the advertiser needs to make buying clicks worth his while. A big part of that is advertising in the correct place.

If you the 'publisher' want control over what ads appear, how often etc. you'll need to remove any risk from the advertiser - CPA/affiliate so that it's always worth it to the advertisers.'

When it's up to the publisher to make the advertising work, they can have control. When it's up to advertisers, they need it. I don't see an obvious way around that.

</comment><comment><USER7> > _For a webapp where you don't have any page reloads, the exsting google > adsense is pretty useless._

You could just auto-refresh the javascript using an iframe if necessary. That would solve that problem at least, although it may raise some additional ones.

<comment><USER2> Inflating impressions by doing something like an auto-refresh is definitely against the adsense TOS.

<comment><USER7> There are sites that do auto-refreshing with other ad networks. AdSense may forbid it, but they're not the only network. I'm certainly not suggesting it as a sneaky thing to do. Some webapps are opened for hours at a time (as the OP stated). Acting as if that multi-hour page view is equivalent to a regular page view and showing only a single ad is ridiculous.</comment></comment></comment>