ThatGeoGuy

Make will check if your dependencies need to be rebuilt, and will only rebuild them if they have changed / been updated.

This is hugely valuable because you can save build times by not needlessly re-compiling the whole world. Linking times are always going to remain the same regardless, but you can definitely make the process more efficient. An example from C/C++ is not generating new object (*.o) files for source files that haven't changed (and who's dependencies haven't changed).

Make also has a pretty standardized syntax and has a bunch of open source implementations. This may not seem to matter since Python has many implementations (as an example), but remember that make is just a program, not a full platform. Python may execute differently depending on the version of Python, the version of any library you're using in the process, or even on the architecture (okay, maybe not in Python so much, but in some scripting languages it could matter). Make only depends on the version of make that you install.

Lastly, make comes with parallelism in your build mostly for free. Calling `make -j4 all` will run up to 4 rules at a time in parallel. In some cases this won't work because your dependencies are tangled in a mess and parallelism can't be guaranteed, but it's a lot easier to get parallel builds for most projects with make compared to something like Python, which either has to use something like the multiprocessing library, or pray that the GIL doesn't bite. In my opinion, this is not something you should be baking yourself into your build system. Make has done it and it has been done right for years.

I think the "we aim" bit is more directed towards certain frequencies rather than "we're not sure if we can get 4G working". Take a look at any group of phones on https://willmyphonework.net and look at the differences between countries. Getting 3G/4G to work globally is a lot harder than just settling for US/Canada or US/Europe.

For those of us less informed: assuming a Matrix <-> PSTN bridge exists, does that mean that one would be able to send and receive phone calls and SMS to existing GSM numbers via a dedicated VOIP number? I don't understand PSTN at all, but wouldn't giving all matrix users dedicated VOIP numbers be difficult and costly?

Further to this, I've actually found in Canada I use Android Pay more and more often now that it's available. The whole country is shifting to contactless and it's incredibly useful to just be able to pull out my phone and make a purchase.

It's faster, and the app gives a list of the purchases you've made with a card, so I can track what I'm spending relatively easily. Unfortunately, there are still lots of stores that haven't upgraded to contactless yet, which means I can't rely on Android pay for the time being. I can see this being much worse in Europe where contactless payments aren't implemented in many more places than here in Canada.

As a corollary to your point about paying money for a free service, I recently decided to help fund Riot/Matrix.org development on Patreon (currently $5 a month). Both are currently presented as a free service, and I recall them stating eventually they would have paid-for integrations and bonuses for corporate users, but predominantly most of the users are on the matrix.org instance using the free service. Needless to say though, it's been a damn good app / backend most of the time, and has made my life much better than before, when I would connect to a handful of various services to accomplish the same goal. I think the reason I didn't see contributing money to be as big of an issue, is that the work is 1) open sourced, which is almost as if I can have some part of ownership in it (don't take this too literally) and 2) I pay $5 for a vps to keep my personal website / email up. If I'm willing to part with $5 for email (which some days could be thought of as not helping my life), I might as well do it for another application / ecosystem I use everyday that does help me in many ways.

Overall I think that to an extent you can't just expect that most people will pay for something that would otherwise be free, or has been free for a long time. You end up gaining a bunch of users from the "lower pool" that will only be there as long as it's a free ride. But a certain class of users will pay for something if you ask for it, because it has made their life better in some way, and they want to ensure it continues in the future. There's an interesting parallel here to Craigslist / Kijiji, where most seasoned users will put a price on items they just want to get rid of. They do this because a very large portion of troublesome users who troll around for free stuff will outright ignore the posting. This actually makes it easier to get rid of things, because you don't have to deal with fielding fifty calls of people who might pick it up but then never show, or who just call you to ask if you have anything else for free that can go with it (and subsequently waste your time from giving unwanted items to people who will actually, you know, come get them from you).

It does make you wonder if the idea of a buffet-style, everything-is-free-forever ends up tainting the user pool, especially with regards to sites / applications that deal with art / multimedia. Sure, there's piracy out there, but companies like soundcloud don't really have the corporate backing behind them to scale infinitely for more users. Maybe from the outset they should have charged a $5 yearly membership or something. They may have had less users, but at least then they'd have something. Or perhaps I just don't understand their business model. Who knows?

Build instructions, and dependency assumptions for starters.

Sometimes the hardest part is just figuring out how to get a project running, or learning what kinds of settings need to be enabled on deployment.

As for craft and actual in-code understanding, I think the masonry example can fit well (see pair-programming as a more fluid example of this). Granted, if you have an API, you probably want to at least document the interface with an example of how to call it. The complex bits of "how is this architect-ed can be better taught by 1:1.

I would argue that you're eschewing Lisp and Scheme in terms of independent, active implementations, however in a more general sense I agree.

Moving fast (and breaking things) is just not what the standardization committee does, and that's fine. They can move faster since C++11/14, but sometimes you really don't want a giant moving target with new features all the time. I think their approach works for the kind of environment you find C++ used in.

I think it gets twisted partially because the quote is wrong. It should be "if a _service_ is free", not "when something is free." I don't think any of the examples you've listed would be considered a service, but rather either a platform (OS) or product.

The quip is certainly overplayed, but I think the notion still stands. It is important to be aware of what intentions service providers and product sellers have. It's not so much a dig on libre / free software.

    > I wonder why there's so much anti-fb commentary on HN?

Well, for starters, the article posted went through many reasons why one might find Facebook hostile, and therefore be very much against it. Anyways, that's not really why I wanted to reply, so here:

    > As for me, Facebook creates an emotional connection unlike
    > any other service out there. I get to see my friends kids 
    > grow up, comfort lost friends when they lose a parent, share
    > with my family when something great has happened. It's 
    > absolutely amazing and there's nothing out there that comes 
    > close to its reach.
    > 
    > If Facebook were suddenly gone tomorrow, I would feel 
    > devastated (so many memories of my kids, deceased father, mom,
    > all would be gone). The only other sites that would provoke
    > a similar emotional response from me would probably be Google
    > and maybe Github.

Now, this is HN so I imagine while I'll come off as very negative, this sentiment isn't all that strange. The problem I see here is that you seem to think you need Facebook to have these same connections. If you want to reminisce on old photos, you can just as easily save them locally. If you wanted to have conversations and save them later, you could use a messenger that isn't trying to mine your data while pulling your heart strings. And yeah, a lot of this type of advice comes off as "there's another product for everything," and "don't put your eggs in one basket," and all that, but there's actually a really strong point here that you're overlooking.

Facebook isn't necessary for any of those experiences. In fact, you state how you wouldn't be able to see your friend's kids grow up, or comfort your friends when they lose someone they love. But was Facebook really the only way for you to do that? It seems to me like you're attributing to Facebook quite a few characteristics that aren't really there. Ditching Facebook and actually meeting with people or staying in touch with the occasional phone call is a hell of a lot more personal. As for all of your memories, fortunately you still have those in your brain. They don't need to be in an advertising archive to be more real.

Isn't this kind of proving the point though?

People go to Amazon for online shopping because Amazon pays to have a bigger web presence through advertising than WalMart does. Had there been no advertising on either end, you'd have a level playing field where people would have to discover the best / cheapest / most efficient online shopping on their own.

Seems strange that you think advertising helps here when you also claim that people are responding to advertising with negative outcomes.

Wouldn't that be a good thing in general though? If we use Hydrogen as our storage format, then you can do the following:

Sea Water (H2O + sea junk) -> H2

Then later when generating electricity:

2 * (H2) + O2 -> H2O (fresh) + energy

Naturally, the resultant H2O can be moved and recycled. I think a catalyst that splits water points towards a potential where we have more fresh water, not less.

To play devil's advocate: you may not need VC's as much in a UBI world. You don't have to worry about income if your startup fails, so you're less likely to play the VC lottery in hopes that you can ride the funding into a successful exit.

This sort of argument always seems eerily reminiscent of the King's morality advisor in the fable of the dragon-tyrant [1]. I don't think most people can grapple with thinking about the benefits of their own demise, much less accept that dying is ultimately the "better" option. I also don't think such a perspective is wrong.

[1] http://www.nickbostrom.com/fable/dragon.html

As a Devuan user (not a dev), it's more than just the init system though. Devuan is also doing lots of heavy lifting to keep udev separate from systemd, as well as other things (consolekit and polkit come to mind, as does dbus).

At this point systemd is a whole lot more than an init system. Most people don't have a complaint with regards to systemd units or how fast it boots, it's more to do with the amount of dependencies it seems to be sucking in (at least from my experience).

One counter objection: LiDAR on drone will be a whole lot less useful if they all 1) collect the same frequency of EM, and 2) have any way of picking up scattered signals from other drones (because it was pointed at other drones, or from scattered reflections).

Right now there's not much in the way of LiDAR on anything, but once there is, we will need to find ways to stop other active sensors from interfering with our own.

This isn't entirely true. Photogrammetric methods that measure depth from stereo-imagery can and often are more "certain, redundant" and precise when the network is structured correctly. What LiDAR offers here is an easy way to get 3D data quickly without a large computational overhead, and no dependency on camera position. It also means we don't have to solve the correspondence problem, that is, finding the same point on two objects between two images.

But LiDAR isn't necessarily enough either. A lot of scanners end up being very noisy, or have a limited range, whereas cameras are good as long as there's line of sight. Using the two technologies together makes a whole lot more sense than just using one or the other.

Disclaimer: I am a graduate student who works with LiDAR, photogrammetry, and 3D imaging technologies.

> I'm pretty sure they tried very hard indeed. They just didn't succeed.

I don't know about this. The last phone they released was the Meizu Pro 5, which had an Android variant (sold in stores) and an Ubuntu variant (sold online only, and you had to dig for it if you didn't get redirected from ubuntu.com). The hardware itself for the phone wasn't awful by any means, but buying one was hard enough because the manufacturer only sold out of Asia.

Further, the Meizu Pro 5 didn't work on most networks in Canada and the United States. Why would I buy a phone that doesn't support 3G/4G? I'd _love_ to support Canonical by purchasing an Ubuntu touch device, but you could hardly say that they tried. Their handsets were few and far between, and they locked out a large portion of the market because of the phone's baseband frequencies.

I think that they could have succeeded, at least in the small, had they actually released a device that power users could use comfortably.

I get that they're moving away from convergence, but what does this ultimately mean for Ubuntu as a mobile OS? In the grand scheme of things, what does this mean for users who want a completely FOSS stack for their phone (let's ignore the baseband for now)?

As far as I can tell, this just means that your only options are Android or iOS. It's not easy to get a Jolla/SailfishOS phone that will work on most Canadian or USA networks, and with this announcement it seems that Ubuntu phones won't be around for much longer. This coupled with the death of Firefox OS means that there's really not much of a choice. Certainly you can run AOSP with no Google Apps, but not having Google Play Services tends to cause more and more problems, or at the very least means your phone is less and less capable as time goes on.

I guess in general we can all celebrate that Ubuntu is moving to GNOME / Wayland and is ditching convergence, but I think the fact that there's no healthy alternative to iOS / Android is quite sad. If Canonical is exiting the mobile space to work on other things, what other alternatives do users have?

Yes, there are numerous examples of "news channels" on Youtube which report on things that more mainstream sources have said or reported on already. Some examples would be Philip DeFranco, Scarce, etc.

> Everyone wants to use the fanciest data structures when most of the times arrays will be faster and simpler to use.

I'm not sure I comprehend this, since I don't often encounter code where people use advanced data structures to do simple things. For most collections, you're typically talking about an array of some kind, since you just want to iterate through many objects doing the same thing. However, there is a reason for more complex data structures to exist. KDTrees, for example, are great for performing nearest-neighbour search, and I can't see any situation where I'd want to use a straight array if I knew I was doing nearest-neighbour searches.

In the most broad, general case I agree: array-of-struct or struct-of-arrays is probably the way to go. You can even see this in the data science world where data frames (effectively struct-of-arrays) are the tool of the trade. However, there are algorithms where if you want an advanced data structure, you really want it (e.g. KDTree). Is it really so common in systems programming to see people trying to incorporate all sorts of magic from The Art of Computer Programming into their programs? I can't say I've ever seen it myself (obvious disclaimer that while I'm a programmer by trade I don't read too many large Rust / C++ projects).

Perhaps we need to clarify our terminology. Typically when discussing HTTPS or TLS, we are discussing transport security, not end-to-end. I wouldn't classify either HTTPS or TLS as end to end, although I can see if you read my comment a certain way it almost seems as if I did.

That said, I am still unconvinced that governments have somehow compromised most end-to-end systems, especially not the ones that experts suggest work (PGP, Signal Protocol, OMEMO, etc). I should make particular mention that compromising and end-to-end system has nothing to do with whether or not a specific target can be made to give you their key(s). If you're being solely targeted by a billion dollar agency, regardless of their origins or motives, you probably won't be able to run or hide for very long. It's important to consider targeted attacks too, but let's not assume Hollywood scenarios here when discussing whether entire crypto-systems have been compromised.

> That's why it's absolutely critical that everything you do is end-to-end encrypted. These government agencies have the resources to crack most encryption, too [3] but at least you aren't making it trivial.

This comment in particular seems to imply that government agencies can break e2e encryption. However, other sources would suggest that's not entirely the case. Snowden, for example, still seems to believe PGP works. I don't have reason to believe that it doesn't, or that the NSA can currently crack any arbitrary 4096-bit RSA keys.

Further, there's a lot to be said about other modern encryption standards (ed25519 curves, forward secrecy and asymmetric double-ratchet protocols like Signal), which I don't believe have been shown to be compromised. I understand the importance of e2e encryption, but it seems that you're overstating the governments ability to crack it. I agree that SSL and TLS don't have the best history, and maybe we shouldn't rely on them, but it is also important to know that there are solutions out there which we still have quite a bit of reason to believe we can trust.

This actually inspired me to set up my daily / monthly backups, which I had not done since upgrading to Devuan almost half a year ago. Fortunately, I had already written a blog post [1] about backups, so setting myself back up and adding a cron task took under 30 min with a fresh disk.

[1] https://thatgeoguy.ca/blog/2013/12/26/encrypted-backups-in-d...

I've only worked through the first paper thus far, but translating it all to Scheme has been a great help in understanding what is going on. If it had been in a nicer language by default, I think I would have lost something from the explanations.

But this just highlights the case with JavaScript even more. In JavaScript nobody is tied to any framework, and they can easily leave for another browser at any time. Heck, with jQuery, it doesn't even matter if you're writing ECMAScript 3 or 6, everything still pretty much works the same out of the box.

At the end of the day there's a lot to be said about the transition from 2 to 3, but I think in general the Python community got off easy compared to some of the breaking changes in other language communities.

This only flattens one level. Consider the following snippets:

    ; CHICKEN Scheme
    #;1> (flatten '((1 2 3) ((4 5) 6) (7 (8) (((((9))))))))
    (1 2 3 4 5 6 7 8 9)
    #;2> (apply append '((1 2 3) ((4 5) 6) (7 (8) (((((9))))))))
    (1 2 3 (4 5) 6 7 (8) (((((9))))))

vs.

    # Python 3
    >>> sum([[1,2,3], [[4,5],6], [7, [8], [[[[[9]]]]]]], [])
    [1, 2, 3, [4, 5], 6, 7, [8], [[[[[9]]]]]]

There's a big difference here. Flattening a list to just the elements inside isn't terribly hard, especially in a language like Scheme with tail-recursion, but flatten is definitely something that should be in the standard library. The "flatten" you propose is really just appending the elements of the first level of the list.

As far as I can tell LastPass also clears the clipboard after you've pasted a password or something from the app. The other day I had to paste my Google password twice and noticed that it was cleared from the clipboard in the meantime.

Not that I know if it helps, since you seem predisposed to Clojure, but CHICKEN Scheme on a Pi also works quite well. We even have direct bindings to GPIO and the like, since someone has gone ahead and packaged a library that speaks to the GPIO through the wiringPi project (http://wiki.call-cc.org/eggref/4/raspberry-pi-gpio).

See https://news.ycombinator.com/item?id=13237674 and my corresponding reply, where you _should_ use array syntax for function arguments, but you need to do it using the `static` index syntax.

I know they're called static array indices, and they're called that because of the use of the keyword `static`, but they don't have to be compile time constant at all (and checks aren't performed at compile time, IIRC). You can have the following:

    void foo(size_t len, int arr[static len]);

Which is really useful in asserting that you won't pass in the null pointer at runtime (so you can remove any `if (arr) {}` checks). Taken further, this exact method is what makes the restrict keyword usable in practice. One of the main problems of the restrict keyword is that you shouldn't be aliasing pointers. By ensuring that your passed-in array isn't actually a null pointer using the above syntax, you avoid one of the biggest problems of aliasing: passing in two null pointers. Consider:

    void foo1(size_t len1, restrict int* arr1, size_t len2, restrict int* arr2);

vs

    void foo2(size_t len1, restrict int arr1[static len1], size_t len2, restrict int arr2[static len2]);

The second is more verbose, but you have a stronger guarantee that this procedure won't be called with pointers aliased to NULL. The compiler can (and I believe in the case of GCC, will) take advantage of this.