Is Ham Radio a Hobby, a Utility or Both? A Battle over Spectrum Heats Up - <AUTHOR> https://spectrum.ieee.org/tech-talk/telecom/wireless/is-ham-radio-a-hobby-a-utilityor-both-a-battle-over-spectrum-heats-up <comment><USER2> A perfect HN automobile analogy for the situation is as follows:

Imagine the govt provides two transport services, a car road service, and a paved bike path service. They're deconflicted and regulated and licensed and taxed separately for various social engineering reasons, etc.

The car roads are congested and I want to drive my semi trailer to the next town, or I just don't feel like paying the tollbooths or whatever. I propose a "brilliant" solution of modifying the regulations for the bike path to allow semi trailers on the mostly empty paved bike path because bicycles are an ancient technology over 100 years old and they should get with the internal combustion times, I don't have a bike personally, I feel my semi trailer is more important than some spandex wearing bicycle hobbyist's amusement, and I don't care about bicycling as a hobby in general, so if I mow down bicyclists while driving my semi down the bike path thus completely destroying the utility of a bike path for bicyclists, I really don't mind. Hey I got mine, I got to drive my semi trailer on the bike path, so at least for me all is well, right?

Now just to make it clear I don't hate bicyclists any more than I think its a good idea to amend part 97 to perform stealthy part 90 operations on part 97 frequencies. I'm merely making a very accurate analogy.

<comment><USER3> But the car roads aren't congested—or, if they are, the bike path is so narrow that using it doesn't actually solve the problem in a long-term way. It's just that you don't need a license to ride a bike the way you do to drive a truck. That's the only (alleged) appeal of the bike lane.

And meanwhile, the people who fear semis using the bike lane (though the semis wouldn't fit anyway) are actually preventing pedal-assist e-bikes, which the younger spandex-wearing bicycle hobbyists would love to use.

<comment><USER4> pedal assist ebikes in bike lanes are quite dangerous. They are just faster, heavier bikes with less braking power.

I'm not saying your point is wrong, just that the analogy is bad.

<comment><USER5> Starting to see these arguments that ebikes should somehow be banned from cyclepaths or bike lanes a lot and not sure I agree at all. Virtually all ebikes sold in North America are limited to speeds achievable on a conventional bike, with most limited to 20mph. An average cyclist on even a cheap road bike can comfortably hit 20mph too if gradient is not too severe.

The faster "class 3" ebikes with 28mph top speeds are already banned from cycle paths pretty much everywhere.

I think we should just be happy more people are getting on bikes regardless. Pedal assist by definition is not a throttle - it's not like the rider has a gas pedal they can leap on and accelerate like a sports car.

As others have said, I'd much rather share a lane with an ebike than a car or motorcycle! Huge speed differentials in the bike lane at times is already a fact of life given varying levels of rider fitness. Just do what most cyclists/ebikers do already - be a considerate rider.

Your argument that they have worse brakes is especially silly - almost all ebike systems only add 7-10kgs to total bike weight vs equivalent non ebike. There are far bigger variances just in rider weight alone. I'd argue ebikes typically have _better_ brakes given most of them are sold with mid to high end hydraulic discs. Typical road bikes are often sold with significantly inferior rim brakes. Modern bicycle disc brakes are extremely good.

<comment><USER4> The question is not whether they have a higher top speed, but whether they are usually traveling the speed of traffic. Pedal assist bikes are _usually_ going significantly faster than bikes in the same area. That's the point of them.

Additionally, that 20 pounds of extra weight is in an uncontrolled projectile. Person to person collisions are not as injurious as bike to person collisions even though bikes are just a fraction of the weight of the person, and that extra 20 pounds triples the weight of most bikes. Talking about rider weight misses the point.

<comment><USER5> Now you are really making things up as you go. 20lbs triples the weight of most bikes? That implies most bikes only weigh ~7lbs. You realise that is completely absurd, and would likely be close to a world record holder for lightest production bike?

Going faster than other riders is absolutely not the point of pedal assist. Most of them basically can't thanks to the 20mph cut out. Of course many will find they can sustain a higher average speed below 20, but the point is travelling much the same kinds of speeds with _much less effort_.

Of course rider weight matters. One is rarely hit by a riderless bicycle. Rider weight is especially relevant in your claim that the brakes are worse too - whether the mass is in the rider or the bike frame is going to be largely inconsequential to stopping distances - the brakes still have to stop the combined weight of rider plus bike. Hence relevance of the small additional mass of small motor plus battery being dwarfed by variances in rider weight on normal bikes.

</comment></comment></comment></comment></comment></comment><comment><USER6> Amateur Radio is a lot like STEM. One of it's goals is to encourage people to get "into" thinking and planning for the situations where amateur radio is a useful public service. The hobby portion exists to give people the freedom to experiment and test their skills.

Part 97 of the CFR[0] actually gives the reason/spirit:

> (a) Recognition and enhancement of the value of the amateur service to the > public as a voluntary noncommercial communication service, particularly with > respect to providing emergency communications.

> (b) Continuation and extension of the amateur's proven ability to contribute > to the advancement of the radio art.

> (c) Encouragement and improvement of the amateur service through rules which > provide for advancing skills in both the communication and technical phases > of the art.

> (d) Expansion of the existing reservoir within the amateur radio service of > trained operators, technicians, and electronics experts.

> (e) Continuation and extension of the amateur's unique ability to enhance > international goodwill.

[0]: [https://www.ecfr.gov/cgi-bin/text- idx?SID=d4b3c60d2d60000a14...](https://www.ecfr.gov/cgi-bin/text- idx?SID=d4b3c60d2d60000a147f885bdee88264&mc=true&node=pt47.5.97&rgn=div5)

<comment><USER7> > Amateur Radio is a lot like STEM. One of it's goals is to encourage people > to get "into" thinking and planning for the situations where amateur radio > is a useful public service.

A few years ago I tried to convince my kids that it would be fun for all of us to get our license for amateur radio. They asked what we could do with it and I told them we could talk to people anywhere in the world! They looked at me like I was nuts because they do that all day everyday online.

<comment><USER8> I'd say "We can receive images from and talk with astronauts on the International Space Station... No big deal, right?" They do this regularly and actually give out certificates for successfully receiving the SSTV images they broadcast, which is super cool IMO. [0]

Regarding cell phones, just yesterday there was a countrywide cellular service outage[1] in Canada, where amateur radio would have continued working flawlessly. Further, if you are doing some backcountry camping or offroading, good luck getting on the cellular network.

[0] [http://ariss-sstv.blogspot.com/](http://ariss-sstv.blogspot.com/)

[1] [https://globalnews.ca/news/5469880/rogers-wireless- outage/](https://globalnews.ca/news/5469880/rogers-wireless-outage/)

</comment></comment></comment><comment><USER9> The article already says what my thoughts on this are (And the thoughts of the people running HAM Radio licensing exams), Ham Radio is a privilege that is granted by the FCC. The specific issue here seems to be that a service that allows HAM communication digitally may be skirting FCC law regulating the use of Amateur wavelengths, which is an issue separate from "the spirit of open communication"., I don't think the "spirit" of amateur radio as everything default open jives with the world we live in today.

Interference is one thing and should be dealth with, but anyone is still able to broadcast QRLs if they want to even in a world of encrypted messages

<comment><USER10> If encryption is permitted on amateur bands, huge chunks of the rulebook become completely unenforceable. Use-cases that would require encryption are largely incompatible with the purposes of amateur radio stated in Title 47 Part 97. If the amateur bands become filled with encrypted traffic, I cannot imagine any scenario in which they would not become a free-for-all.

<comment><USER11> I've always wondered why the FCC is regulating the _content_ of amateur radio transmissions as opposed to merely the spectrum used. With the way regulations are set up, there's little to do on amateur radio than....talk about amateur radio. A bit stifling as far as potential innovations go. I've had several great ideas for amateur radio applications that are effectively useless without some method of privacy.

There's not a compelling reason I can think of for the FCC doing anything more than regulating bandwidth, power, and duration of radio spectrum signals. On that premise, what couldn't they do with encrypted signals? It's not like abusers honestly identify themselves at the required intervals anyway. They could still triangulate abusers and issue fines. The only thing they wouldn't be able to do is tell users to watch their mouth.

As far as one of the stated purposes being emergency management, I can't help but wonder if reserved frequencies (ala CB channel 9) are sufficient.

<comment><USER12> Could you give an example of how the regs stifle? If you can avoid obscenities you can talk about whatever you like. Your political views, the asking price for your unused HT, whatever.

<comment><USER13> > Could you give an example of how the regs stifle?

As I pointed out just a few days ago, probably most hams worldwide interpret the regs as discouraging any polemic discussion like politics or religion. Since so many hams are elderly, there is also some distrust of foreigners lingering from the Cold War era. So communications, especially international communications, are so often limited to merely exchanging signal reports, maybe some gear talk or weather info, and then it's 73.

Besides that, amateur radio is a hobby that attracts a lot of socially-awkward anoraks, who are very self-conscious about entering into any conversation deeper than just talking about their gear.

Sure, there is a community of eager ragchewers, but it is not so big comparatively, and even most of those ragchewers probably limit their deep conversations to people from the same country (or even to people from their own local club scene).

<comment><USER14> I guess you're not familiar with 14.313 MHz...

(It's been called the 4chan of ham radio)

<comment><USER13> And that hangout represents how many hams worldwide? Let's have a sense of perspective.

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> These guys were the original hackers !!! I knew a lot of these guys, they were taping 2meter repeaters with these funky handheld radios that looked like a phone way back in the late 70's, I thought they were kookokoobooros.. but turns out... Before you totally dismiss some geeky dude with some weird thing, think about this. Back in 1978 [I get it I am old but just hear me out here] Way back then these guys were talking with each other with these 2M "walkie talkies" over these "community repeaters". Back then it seemed pretty kooky to me. Now, looking back, they were very geniuses (I think) You just never know when a bunch of hackers building their own PC's or their own cell network, will take things. We need to keep a space for hacker, experimenters. I think it is critically important to always find a way to make sure there is some space carved out for experimenters. That is why I believe we need to keep some amount of spectrum reserved for "experimenter". You just don't know what will come of it. Again, IMHO.

</comment><comment><USER16> To note for other people: This is about digital modes, not the recent arguments about that french company trying to take the 2 meter band.

<comment><USER17> It's not about all digital modes. It's about proprietary digital modes. As the petition says:

> Almost all digital modes in common amateur radio use are capable of being > monitored by third parties, either through an integrated developer provided > software package, or with a stand alone software decoder. Problems arise > when protocols and devices used in commercial, government, and marine > services are used in the amateur service with no adequate means to fully > decode transmissions. Further complicating the situation are security and > privacy features of the specific modulation and networking protocols which > are not subject to rules governing amateur radio. Said features preclude the > amateur radio community from attempting to monitor the Part 97 spectrum by > denying them ability to eavesdrop

and the proposed solution is

> To rectify the current situation in the amateur radio service,digital mode > developers must be required, by Part 97 rule, to provide the means to fully > decode their product in amateur use to enable monitoring and self-policing. > The amateur radio community, the FCC, and intruder monitoring groups should > not be put in a position of having to develop decoders for any digital > protocol destined for use in the amateur radio service. The protocol > developers should be solely responsible for providing a decoding solution to > ensure Part 97 rules compliance. Any necessary software provided by > developers must be open source, unencumbered by patent, licensing > fees,royalties or copyright, in keeping with the intent and spirit of the > amateur radio service as exemplified in Part 97.1(b)(c).

[https://ecfsapi.fcc.gov/file/100918881206/PETITION%20FOR%20R...](https://ecfsapi.fcc.gov/file/100918881206/PETITION%20FOR%20RULEMAKING.pdf)

<comment><USER18> What about people trying out new, experimental digital modes? Should that not be allowed?

<comment><USER17> The petition doesn't say they shouldn't be allowed. It just suggests the people developing such modes must provide the means to decode them.

</comment></comment></comment></comment><comment><USER19> AM (CW) -> AM voice -> SSB -> FM wide -> FM narrow -> Digital

Modes have to evolve and the amateur radio community needs to do more to educate. The harrumphs of the old-timers can be discouraging, but amateur radio needs to push through that in order to stay current.

<comment><USER20> There's nothing wrong with digital modes. It really is the next evolution for ham. But there is something wrong with proprietary, blackbox encoders that only allow people with specific radios or licensed software to use it.

The world got onboard with 802.11g (and even 802.11b but that sucked). That was a massive movement towards the proliferation of wireless devices. While the standard costs $178 from IEEE, you can find copies of it scattered all over the internet. I don't know why hams have adopted these closed standards, I'm guessing it's because at one point the hobby was dominated by elmers too old to figure out anything but the newest expensive shiny thing from Icom or Yaesu (too much money, not enough sense...) Nowadays you can pull up GNU Radio and start using any sort of open standard mode you want because of how accessible everything is.

</comment></comment><comment><USER21> The concrete example provided by the article is the potential for opaque transmissions via Winlink, which could reduce transparency and thus raise the potential for abuse of the limited spectrum. I knew nothing of Winlink (or this petition) before today, but I was wondering why it necessarily has to be encrypted. A transparent Winlink service could surely be compatible with the spirit of Amateur Radio in the same way that packet radio is, right?

From a brief Googling leading to Winlink's web site, it sounds like Winlink isn't even encrypted at all [1]:

> _Q260 While monitoring transmissions from WL2K stations, I notice that the > content appears as "gibberish". Isn't this illegal?_

> _A260 The content looks that way because it is a compressed binary format > called "B2F." This format is available to anyone, so the compressed data is > not considered encryption or illegal for radio amateurs._

Is the concern that people are encrypting Winlink payloads anyway? And wouldn't this already be illegal under current rules?

[1] [https://www.winlink.org/sites/default/files/wl2k_faq_2015031...](https://www.winlink.org/sites/default/files/wl2k_faq_20150314.pdf)

(Edit: formatting)

<comment><USER17> The concern with winlink is twofold:

1) It transmits without checking if the frequency is already in use, and is thus a source of interference to other users

2) It uses a proprietary protocol that requires purchasing expensive hardware froma single company ([https://www.p4dragon.com/download/SCS_Pricelist_2019_REV-A.p...](https://www.p4dragon.com/download/SCS_Pricelist_2019_REV-A.pdf)) to decode

The solutions proposed are

1) Limit "Automatically Controlled Data Stations" like Winlink to a specific range of frequencies 2) Limit the protocols they use to ones that "can be be monitored, in it's entirety, by 3rd parties, with freely available open source software"

You can read the petition at [https://ecfsapi.fcc.gov/file/100918881206/PETITION%20FOR%20R...](https://ecfsapi.fcc.gov/file/100918881206/PETITION%20FOR%20RULEMAKING.pdf) for more details.

<comment><USER22> While Winlink can use the Pactor protocol, it is not required to use the system. Winlink is capable of using multiple protocols each of which fit to frequency, hardware and band conditions.

[https://en.wikipedia.org/wiki/Winlink#Technical_protocols](https://en.wikipedia.org/wiki/Winlink#Technical_protocols)

</comment></comment></comment><comment><USER23> Recently proved itself as an essential utility in Puerto Rico, right?

<comment><USER24> Imagine a hypothetical private company with a radio system that is used 5% of the time for important messages in major emergencies, and 95% of the time for billionaires' yachts.

In a genuine emergency where many lives were at stake, one might give them great leeway to break the law, just like fire trucks can speed and run red lights.

But when there's no emergency, should such rulebreaking be allowed for the billionaires' yachts?

Obviously, the e-mail-by-radio system at the heart of this argument isn't all about billionaires' yachts - but still, there's no reason loosened rules for emergencies should be extended to non-emergency use.

<comment><USER25> Seems hyperbolic. Considering the transfer speeds and relatively low cost of sat internet I sincerely doubt that "billionaires" are using winlink to a point that is interrupting the global ham radio band.

[1] [http://www.groundcontrol.com/MCD-4800_BGAN_Terminal.htm](http://www.groundcontrol.com/MCD-4800_BGAN_Terminal.htm) [2] [https://www.winlink.org/sites/default/files/download/wl2k_fa...](https://www.winlink.org/sites/default/files/download/wl2k_faq_0.pdf) (see A170)

<comment><USER26> Theres a decent number of people who use Winlink as a substitute for Sailmail and thusly are in violation of 97.113(a)5.

<comment><USER27> Why do they do it? Is it a cost or convenience issue (or both)?

</comment></comment></comment></comment></comment><comment><USER28> These days, an important skill is security, and security thinking, which requires modern encryption. The government currently demands to eavesdrop on all ham communications. Well, of course it does. It's a government. Standing up to such nonsense is a skill in itself, and one which should be cultivated.

</comment><comment><USER29> The Administrative Procedures Act provides great processes to express yourself. I highly doubt this Petition for Rulemaking would proceed to a Notice of Proposed Rulemaking. The Commission rarely conducts proceedings to adopt or change rules in Part 97 since 2001. I expect a dismissal letter to eventually issue forth more than anything else.

</comment><comment><USER30> Hobby now. Utility once the zombie apocalypse starts.

</comment><comment><USER31> This fight has been brewing for a long time and I've been a user on both sides. I sailed across the Atlantic in 1993 and 1996 and we used a Pactor modem and a service called Sailmail to send and receive email via marine HF radio (1 to 30Mhz). The service is still active and is an alternative to Winlink unless things have changed.

I'm a licensed ham these days (WT1J) and use HF for my hobby. I use voice and open source digital protocols. All for fun and learning.

I think the reality here is that Sailmail and Winlink are used by folks to check their email and they treat it like regular email, which means they conduct business over it. The system has become popular with yachties around the world - many of whom are wealthy retirees or remote workers.

In the 90s, using a Pactor modem and SSB was pretty much your only cost effective option to have any kind of email access.

These days you can buy an Iridium Go for less than a Pactor4 modem and the rates are reasonable for text and email. In fact Sailmail integrates with Iridium Go now.

I think the arguments made for banning Pactor modems on the HF bands are legitimate. Other than Pactor 1 which is open source, Pactor 2, 3 and 4 are proprietary and you can't decode them if you're listening in.

You are also not supposed to use the amateur bands to conduct business, and yet that is exactly what is happening much of the time someone is downloading/uploading email via a Pactor modem on the amateur bands.

From the FCC: "The amateur and amateur-satellite services are for qualified persons of any age who are interested in radio technique solely with a personal aim and without pecuniary interest. These services present an opportunity for self-training, intercommunication, and technical investigations." Source: [https://www.fcc.gov/wireless/bureau- divisions/mobility-divis...](https://www.fcc.gov/wireless/bureau- divisions/mobility-division/amateur-radio-service)

So checking your stock portfolio from the Bahamas or communicating with your lawyer is not allowed. However this is near impossible to monitor because Pactor 2+ is proprietary and so no proof of this can be submitted.

What the hams are arguing for is in the spirit of the amateur bands: Make the protocols open source and unencrypted so that all communication on the amateur bands are essentially open source and we can all participate and help regulate each other - while learning from each other.

This feels reasonable to me. Kick the Pactors off and let them use Iridium or Inmarsat.

PS: I don't buy the 'interference' argument mentioned in the article. Pactor is low bandwidth and doesn't cause interference that I'm aware of. It's just occupying some bandwidth and can't be understood by others.

<comment><USER17> Sailmail does not use the amateur bands, so it wouldn't be affected; it is licensed under [https://www.fcc.gov/wireless/bureau-divisions/mobility- divis...](https://www.fcc.gov/wireless/bureau-divisions/mobility- division/maritime-mobile-service)

</comment></comment><comment><USER32> A bigger issue is RM-11831 would also ban DMR, P25, and pretty much every digital mode used on VHF as well, because of its open source requirement - currently every ham digital audio mode uses codecs from DVSI.

<comment><USER33> Proprietary patent encumbered digital modes have done a lot to ham string ham radio: They have resulted in a proliferation of mutually incompatible radios and repeater systems which otherwise could be totally compatible just with a different setting or firmware load.

In addition to that most obvious annoyance, encumbered modes have restricted experimentation and exploration. Compare the vibrancy and progress in the open source HF low bandwidth modes implemented by WSJT to the level of technical development at the modem or codec level for dstar.

FWIW, my recollection is that the AMBE patents are soon due to expire, if they haven't already.

<comment><USER32> Both P25 and DMR are open standards, the only closed part is IMBE (which I believe is patent free now) and AMBE+2 (which will be patent free in the next 5 years). DSTAR is also a open standard too, but I think only has a single implementer, same for C4FM.

</comment></comment></comment><comment><USER34> Since they're both valid uses, let's just partition/segregate the freq bands and be done with it.

</comment><comment><USER35> my kingdom for an icon next to each user handle in this thread that shows whether or not they are or ever have been a licensed amateur...

</comment><comment><USER36> I'm Mary Ham, and welcome to Ham Radio.

</comment><comment><USER37> It could be argued that when all you had were AM/CW receivers, plain old SSB would have been an encryption scheme, if the definition of encryption is "there's someone who cannot demodulate it with the equipment they have".

<comment><USER38> Part 97 ([http://www.arrl.org/part-97-text](http://www.arrl.org/part-97-text)) does not even contain "encryption" . The rule is:

> §97.113(4) Music using a phone emission except as specifically provided > elsewhere in this section; communications intended to facilitate a criminal > act; messages encoded for the purpose of obscuring their meaning, except as > otherwise provided herein; obscene or indecent words or language; or false > or deceptive messages, signals or identification.

The "messages encoded for the purpose of obscuring their meaning, except as otherwise provided herein" being the key part and the "except as otherwise provided herein" basically boiling down to remote control (incl for satellites!)

It's also tricky because the FCC allows proprietary voice codecs on the mature bands. They are not considered as "obscuring" the meaning because even though they're not an "open" standard, anyone with the appropriate decoded, can decode the voice stream. I guess because it's a globally shared secret and not a shared secret only between the sender and receiver, they allow it under the rules.

Even experimental digital modes on the amateur bands don't fall afoul of this rule. You can experiment with a new digital mode that no one but you has the ability to decode. However, if push came to shove you'd need to release at least a functional description of your mode or forfeit your license.

It's not an encryption or cryptography ban -- signed messages are perfectly fine -- it's really an extension of the whole idea that these bands and your license exist for the purpose of shared, non-commercial communication of a personal nature in a public space.</comment></comment>


Only 25 Percent of Yahoo Employees Willing to Eat Mail "Dogfood" - <AUTHOR> http://allthingsd.com/20131124/while-users-lament-only-25-percent-of-yahoos-willing-eat-mail-dogfood-memo/

<comment><USER2> Not that big of a shocker. Wondering what are the stats at Google :)</comment>


Is It Time to Let Employees Work from Anywhere? - <AUTHOR> https://hbr.org/2019/08/is-it-time-to-let-employees-work-from-anywhere <comment><USER2> I think there are jobs where having the WFH option would be beneficial to both the employer and the employee. Some creative, computer jobs can be done from home or could be done half from home and half from the office. It allows for flexibility but should be considered a privilege - especially if work is not continuously done up to par.</comment>


Boeing seeks $10B in loans as 737 Max crisis continues - <AUTHOR> https://arstechnica.com/tech-policy/2020/01/boeing-seeks-10-billion-in-loans-as-737-max-crisis-continues/ <comment><USER2> Ironic given that I've seen estimates that Boeing spent 20-40B in stock buybacks.</comment>


Built for Bitcoin. Next Run: Early 2014 - <AUTHOR> https://lamassu.is/

<comment><USER2> It's not a "Bitcoin ATM". It's a "Buy Bitcoins for cash" machine. And there is a huge difference.

I'll get excited when I see a machine that DISPENSES cash for Bitcoin, anonymously. That will be a breakthrough. For the moment, in spite of many claims, Bitcoin remains the most easily trackable currency and there is no way that I know of to get money _out_ of the Bitcoin system in a way that can't be tracked.

<comment><USER3> > there is no way that I know of to get money out of the Bitcoin system in a > way that can't be tracked.

[https://localbitcoins.com/](https://localbitcoins.com/)

> LocalBitcoins.com is a marketplace for trading bitcoins locally to cash or > online payments of your choice.

<comment><USER4> IANAL, but from my layperson's understanding of FinCEN's statements, selling bitcoins on localbitcoins.com (indeed, even offering to sell them) without a MSB license is a felony.

I deleted my profile on there when someone pointed that out to me.

</comment></comment></comment><comment><USER5> This machine accepts tons of world currencies. This will be much to the disadvantage of its owner, who will now have to try to change $20 in each of a dozen currencies to the local fiat currency. Doing this will be somewhere within a triangle of difficult, annoying, and expensive. Once owners figure this out, they will probably demand a way to program their machines to reject most currencies, just like everyone else does.

Accepting "currencies from over 200 countries" is not a good thing when there aren't that many countries in the world with currency you'd want to hold. Nor does it reassure us about the machine's ability to reject counterfeit notes-- owners won't be able to verify notes they don't normally use, and BTC will ensure that fraudulent depositors have low risk of being caught.

<comment><USER6> I think it means the note acceptor is physically capable of recognising notes from 200 countries. You presumably only configure it to accept notes from one currency at a time.

</comment></comment><comment><USER3> I think "Bitcoin ATM" should feature in the title.

</comment><comment><USER7> I'm not sure if the "compact size" is such a good thing - There is a reason why ATMs are so big..

(A junkie with a crowbar)

<comment><USER8> I would love to see these in airports! There's already lots of security there so no need to make them huge.

<comment><USER9> I'd like to see the reverse in airports: Land in some strange country, immediately get local currency for bitcoins.

<comment><USER10> The device might be interesting though. If you have some remaining bills and you are lazy to convert them. I have, maybe, $100 of cash in many different currencies remaining from my travels.

</comment></comment></comment></comment><comment><USER11> I used one of these the other day to try to buy $1 worth of bitcoin. It spun forever and I had to leave. Don't know if it ever actually went through or not, but it should've given me a timeout message way before 5 minutes of standing there.

<comment><USER12> Really? I'm kind of amazed by this whole thing - I never thought there would be a desire to purchase bitcoins in real life with physical cash. I always thought of it more as a online thing people would do via exchanges, smart phone apps, etc.

If you don't mind me asking - Where was the machine? Why were you buying bitcoins there vs just using an online exchange?

<comment><USER13> I guess it adds another layer on anonymity to it. Online exchanges often require your name and address, and even if they don't, you're probably going to be funding it via a debit card or bank account which can be traced back to you. By using cash, there's no way of identifying who purchased the bitcoins (except via cctv I guess)

</comment></comment></comment><comment><USER14> What's the business model for operators/buyers of the Bitcoin machine?

<comment><USER15> "The operator of the machine, be it the distributor or individual owner is responsible for loading the machine with bitcoins. In other words, he who holds the private key."

"The operator of the machine sets the fees and ticker prices. That too is easily set via the administrative interface."

</comment></comment><comment><USER16> It's a bitcoin vending machine. Owner of a bar/cafe/shop can accept bitcoins for payments and load them in this machine to convert them to cash. Those who want to spend bitcoins don't need to find those who want to buy them.

Shops have easier way to accept and convert bitcoins into local currency => more places to spend bitcoins => more places where to buy bitcoins => more people using bitcoins => value grows => more shop owners are interested in keeping some BTC as an investment => less need for local currency => less friction => more bitcoin adoption => local currencies die out of hyperinflation (aka massive sell off) => fully deflationary economy => we all die in a deflationary spiral (not really ;-)

<comment><USER17> The machine doesn't do BTC to cash, but rather the other way around.

<comment><USER18> Indeed, but a cafe owner can accept bitcoins as payment for their goods, and then sell those same bitcoins to the public via the machine. This takes away _some_ of the friction from bitcoins becoming just another payment form like credit cards.

<comment><USER17> Good point. I hadn't thought of that workflow :)</comment></comment></comment></comment>


The world needs more modest, linear growth companies. Please make some - <AUTHOR> https://m.signalvnoise.com/the-world-needs-more-modest-linear-growth-companies-please-make-some-609b5a10a9e0 <comment><USER2> I agree we need to companies that don't chase exponential growth. That being said, I am not sure if this advice is broadly applicable:

1\. If you take VC money, they are not going to keep giving you more money if all you can show is linear growth. It may take a really long time for the company to become self-sustaining and just will not work with VC economics. Expecting them to change their mindset is not realistic unless the fundamentals also change.

2\. If you don't need VC money, then you probably are not chasing exponential growth anyways. You have limited capital so you build a sustainable business (if your idea has legs) by chasing meaningful growth. So this article does not impact these companies.

3\. If you are one of those rare companies that need some good amount of capital initially (hard to penetrate industry like healthcare or finance) but once established, maybe you can build a sustainable business without a lot of new capital. For this group this advice may make sense, find VCs who believe in linear but sustainable growth but you are definitely viable and the returns are still going to be attractive as you may need only 2-3 rounds of funding.

I would guess the number of startups that will fall under #3 is going to be really, really small.

In short, the article could have just argued for more bootstrapped businesses. But then, there may be many such companies already and we just don't hear about them... So maybe the article's point is to make more of those startups more visible so not everyone thinks they need exponential growth.. That just requires all consumers to crave stories that are ordinary so media companies can start writing less sensationalistic articles... maybe that's the billion dollar startup with linear growth!

<comment><USER3> For #3, [http://www.indie.vc/join](http://www.indie.vc/join)

</comment></comment><comment><USER4> I agree with many of the tangential points in the article, especially the point regarding monopolies and oligopolies made up of rapidly-expanding companies. But while I appreciate the sentiment of the core argument, the math doesn't treat it kindly.

A company that is growing linearly is necessarily growing at a decreasing rate as a factor of its size. Absent dividends or share buybacks, "size" here can refer to equity outstanding; in that case, returns to owners/shareholders will necessarily decrease over time as a proportion of their equity. Alternatively, by regularly issuing dividends or repurchasing shares, a company that is growing linearly by some metric other than equity (e.g., profit) can provide constant or better returns by concentrating its profits within a smaller equity base. But that just forces its shareholders to invest elsewhere, and to avoid decreasing returns over time, their money must ultimately find its way back to a company that is growing exponentially.

Admittedly, that argument probably seems nitpicky - the article could just as easily referred to slow, stable exponential growth rather than linear growth. But for startups, that still creates a poor risk-reward tradeoff, because many (though not all) of the risks that apply to fast-growing startups also apply to slow-growing ones. Your ideas may not be marketable, or you may not implement them properly, or an established player may jump in and take over your market, or whatever. Why should an investor take on that risk, in exchange for blue-chip-like returns in the best-case scenario, when they could just invest in established blue-chips instead?

For a particular founder with the right business model, there are workarounds for this issue. You don't have to be dependent on external investors if you can get started with a small amount of capital, operate and scale efficiently, and turn a profit early enough to remain solvent. But those constraints are significant enough, and the rewards for succeeding are modest enough, that I think it's unrealistic to expect the "proliferation of a thousand or million smaller businesses" that the article refers to.</comment>


Against privacy defeatism: why browsers can still stop fingerprinting - <AUTHOR> https://freedom-to-tinker.com/2018/06/29/against-privacy-defeatism-why-browsers-can-still-stop-fingerprinting/ <comment><USER3> Over the years I've noticed this, privacy defeatism, amongst other excuses used to push back against security and privacy enhancements.

Another is security chicken and egg. "Because A isn't secure, there's no point in securing B. And because B isn't secure, there's no point in securing A." I've seen arguments along those lines used against improving the security of, for example, DNS and SNI. Or just DNS in general. "There's no point in securing DNS because your ISP can see what IP addresses you connect to."

The all-or-nothing argument has been used to argue against HTTPS. "State actors like China can circumvent HTTPS, since they control trusted CAs! So why use HTTPS at all?"

Then there's the arguments against security because "it makes development harder!" People have argued against mandatory HTTPS saying that it makes developing websites harder.

The list goes on.

Luckily it seems that pro-security and pro-privacy succeed in the end, for the most part. But those that use these pathological arguments have certainly delayed things more than they should have been.

<comment><USER4> I'm not a privacy defeatist, but I am a fingerprinting defeatist. Here's why: I don't think it's realistic for caching and anti-fingerprinting to co-exist, and given those two options users will always pick the former because the latter would be perceived as slow. The classic example is:

<script src=foobar.js>

Where foobar.js just returns something like "var id=0x1234567", the user who doesn't want to be fingerprinted cannot cache this script because it could be uniquely generated.

<comment><USER5> Why not cache it for the user, but go ahead and retrieve it in the background?

<comment><USER4> I don't understand the question, it's either cached or not.

If it's not cached, then it has to be fetched synchronously for anything depending on its value to work - so it's slow.

If it is cached, then the cached value is known.

</comment></comment></comment></comment><comment><USER6> Chrome has no interest in doing that.

Google uses browser fingerprinting for their ads, and to make sure a real user is requesting their services.

I would trust Safari a lot more to implement something like this.

<comment><USER7> That is a big reason I stopped using chrome. I block all the cookies and scripts I can but they were still collecting data from other shit and serving me obvious directed ads.

<comment><USER8> I don't know about Google, but AIUI FB does targeted advertising based on source IPs if there's a very small number of users from a given IP.

As long as they know the source IP, they can implement some form of tracking.

</comment></comment></comment><comment><USER9> There are two ways to defeat fingerprinting: 1) Be common: have your data match what others are sending 2) Be unique on every page request: scramble your data

Browsers in category (2) are not trackable, even though they appear to be fingerprintable. Each page request is a different fingerprint.

What is unclear from the article is whether the studies mentioned (EFF, INRIA) considered that and tested that. Does anyone know? Because privacy does not require non-unique fingerprints, it just requires untrackability.

<comment><USER10> Are there any readily-available browser plugins (or whatever) that implement (2)?

<comment><USER11> Firefox has two about:Config settings, one stops canvas fingerprinting, the other notifies.

Other settings stop giving out a list of plugins or fonts. And e.g. unlock or umatriz can rotate your user agent.

It's not perfect, but with a few tweaks Firefox is much much harder to fingerprint - though IPv6 tends to undo all of that because many providers assign a prefix per customer which will never change and can be used by anyone to correlate.

<comment><USER8> How common is the setup those settings put you in, though? Are you more or less unique in that bin?

</comment></comment></comment></comment><comment><USER12> > why browsers can still _stop_ fingerprinting (emphasis mine)

> privacy defenses don't need to be perfect. Many researchers and engineers > think about privacy in all-or-nothing terms

So browsers can't stop fingerprinting but they can reduce it, and the article author's title falls in the same all-or-nothing trap that they criticize others for. Too often practicality is viewed as defeatism. I don't remember defeatism, I remember practical limitations to stopping all uniqueness vectors but realization that some can be stopped.

<comment><USER10> I remember somebody who worked with Firefox saying that even the idea of not by default revealing the OS and hardware platform received too much opposition.

</comment></comment><comment><USER13> To be clear: Yes we should fight fingerprinting...

But: I don't care if only 5% of internet users are uniquely identifiable. I care if _I_ am uniquely identifiable.

<comment><USER14> If you are not uniquely identifiable but 99% of the users are that's enough to identify you. That's why US Navy funded the tor project. If their people were the only ones that could hide from other governments then those other governments knew who those unidentified people were.

<comment><USER15> This is also a big issue with NoScript and similar plugins. A very small percentage of real users (ignoring bots and headless browsers and such) intentionally disable JavaScript, so they're painting a target on themselves while trying to do the opposite.

<comment><USER9> This is true. However, most users of NoScript/uMatrix/uBlock are blocking the script that actually does the fingerprinting. So while the server could infer information because the script didn't run, usually they get no notification and tracking simply fails.

<comment><USER16> For once, let's thank web developers who assume everyone has javascript enabled.

</comment></comment></comment></comment></comment><comment><USER17> The whole article seems to be based on this study:

[https://www.doc.ic.ac.uk/~maffeis/331/EffectivenessOfFingerp...](https://www.doc.ic.ac.uk/~maffeis/331/EffectivenessOfFingerprinting.pdf)

And sees it as an indicator that preventing fingerprinting is possible:

        Only a third of users had unique fingerprints,
        despite the researchers' use of a comprehensive
        set of 17 fingerprinting attributes.

To me, the 17 attributes do not seem comprehensive at all. For example they don't make use of the users IP. So much can be derived from the IP. Carrier, approximate location etc. They also don't use the local IP, which is leaked via WebRTC:

[https://browserleaks.com/webrtc](https://browserleaks.com/webrtc)

They also don't seem to measure the performance of CPU, RAM and GPU when performing different tasks.

But yes: Browsers should do more to prevent fingerprinting. But it seems they have no inclination to do so. That they don't plug the WebRTC hole that leaks the local IP is a strong indicator for me that privacy is low on the list of the browser vendors. Or maybe not on the list at all.

</comment><comment><USER18> There's generally a tradeoff between usability and performance, and resistance to fingerprinting. If your browser has WebGL enabled, the machine (not just the browser) can be fingerprinted. If it caches resources, adversaries can discover browsing history.

<comment><USER19> > If your browser has WebGL enabled, the machine (not just the browser) can be > fingerprinted.

Curious, how would that work exactly? (I've never used WebGL yet in any code).

> If it caches resources, adversaries can discover browsing history.

Same question. I was under the impression that cached resources can be accessed only by the domain that introduces them.

<comment><USER20> This paper discusses the details:

[http://yinzhicao.org/TrackingFree/crossbrowsertracking_NDSS1...](http://yinzhicao.org/TrackingFree/crossbrowsertracking_NDSS17.pdf)

You can also visit their site to see it in action: [http://uniquemachine.org/](http://uniquemachine.org/)

<comment><USER18> And re the demo:

> Your graphics card does not seem to support WebGL.

So NoScript is blocking WebGL, as promised.

</comment></comment></comment></comment><comment><USER21> The irony seems to be this:

> _But there's another pill that's harder to swallow: the recent study was > able to test users in the wild only because the researchers didn't ask or > notify the users. [2] With Internet experiments, there is a tension between > traditional informed consent and validity of findings, and we need new > ethical norms to resolve this._

So the result of their privacy-advocating study was itself only obtainable by breaching the privacy of their participants. (I.e. making them participants without them knowing or consenting to it)

</comment><comment><USER22> The article mentions Canvas, Battery, Audio,and WebRTC. Should these all request a user OK before being used?

<comment><USER23> Definitely for high entropy APIs at least. Checking if audio or canvas exists is just two bits.

But e.g. being able to read canvas pixels is absolutely insane that it's allowed.

So if just these sources of huge entropy were default swithed off, as the article says, fingerprinting would be a lot harder.

<comment><USER24> Especially, canvas would become useless in an opt-in scenario and would just foster permission fatigue (people just clicking "Allow" because it makes those dialogs go away).

Another option might be to define closely (pixel-by-pixel) how a canvas should look like after a specific action. That way vendors would have less room for 'their way' of drawing things but the result would look equal and would be useless for fingerprinting.

Similarly, one could define a list of fonts which every browser should bring and all other fonts should be loaded from a server. It would eliminate the 'you have special fonts installed' problem completely.

<comment><USER23> The canvas wouldn't be opt in, only the _pixel reading_ feature would be - <USER2> that's an edge case that I can't imagine being used in even one in a thousand uses of Canvas. Just drawing to a canvas has no privacy implications and covers almost all uses.

</comment></comment></comment></comment><comment><USER25> "Another lesson is that privacy defenses don't need to be perfect. Many researchers and engineers think about privacy in all-or-nothing terms: a single mistake can be devastating, and if a defense won't be perfect, we shouldn't deploy it at all."

This "all-or-nothing" perspective is rampant on www forums discussing computer topics and certainly HN is no exception. It is particularly acute in any discussions of "privacy" or "security".

There are countless examples.

Earlier this week the topic of SNI rose again to HN's front page.

A minor percentage1 of TLS-enabled websites require SNI. An unfortunate side effect of SNI is that it makes it easier for third parties to observe which websites users are accessing via TLS because it sends domainnames unencrypted in the first packet.

Forum commenters will thus argue because there are other, more difficult means for some third parties to observe these domainnames, e.g., through traffic analysis, that the unencrypted SNI is therefore not an issue worth addressing.

All-or-nothing. If the privacy achieved by some proactive measure is not "perfect" then to these commenters it is worthless.

But the HN front page reference suggested otherwise: It was an RFC describing how the IETF is taking a proactive measure, trying to "fix" SNI, encrypting it to prevent third parties from using it in ways detrimental to users.

There is an easier proactive measure. The popular browsers send SNI by default, even if the website does not require it. The default behaviour is to accomodate a minority of TLS-enabled websites at the expense of all users, including those who may not be using this minority of websites.

To make an analogy to fingerprinting, imagine sending 17 unique identifiers with every HTTP transaction when, say, only 5 are actually needed. The all-or- nothing perspective adopted by forum commenters would dictate that it makes no sense to reduce the number unless the number can be reduced to zero.

Amongst the security folks there is a concept sometimes called "defense in depth". Commenters in discussions about security often agree there is no such thing as "perfect" security and they cannot rely on a single, "silver bullet". They must use multiple tactics.

Is privacy somehow different? There are many tactics users can take that, cumulatively, can make things more difficult for the data collectors.

1 Survey of websites currently appearing on HN

Number of unique urls: 367

Number of http urls: 43

Number of https urls: 324

Number of https urls requiring SNI: 38

Number of https urls requiring correct SNI: 26

"Requiring correct SNI" means SNI must match Host header.

Summary

One can fetch 286 of the 324 https urls currently posted on HN with a HTTP client that does not send SNI.

An additional 12 can be retrieved by sending a decoy SNI name that does not match the Host header.

</comment><comment><USER26> There is Privacy Possum, a Firefox and Chrome extension that works better against fingerprinting than Privacy Badger:

[https://github.com/cowlicks/privacypossum](https://github.com/cowlicks/privacypossum)

<comment><USER27> How does it differ from Privacy Badger? (In goals, threat model, implementation, etc.?) I found the readme to be a little incomprehensible.

</comment></comment><comment><USER28> It starts saying all the right things, I was, like, expecting real tech stuff, after intro, and ... post ends.

Where is per browser stats, correlations, data points and features? Canvas vs IP vs User-agents?

<comment><USER29> That's what hypertext is for. Follow the links.

</comment></comment><comment><USER30> What is needed is a community written and funded privacy browser. Mozilla the billion dollar non profit and Firefox their so called privacy first brwoser is the biggest exfiltrator of user data. Their default 5000 user settings are all geared towards feeding them and Google real time user activity feed. They have moved from being Google data bi.ch to a major data collection thug themselves. As such fingerprinting becomes at best a tangential issue.

</comment><comment><USER31> Sets up a straw man of " _privacy defeatism_ ", then knocks it down with an analysis of some French website's logs-- _as though any of this were a technological problem in the first place_.

This is not a case of " _defense in depth_ " or " _something is better than nothing_." This is the case of a surveillance capitalism asset performing to spec.

Privacy in the browser is/was f-ed, plain and simple. Patch one hole, make two more. That's how it's been for at least 20 years now. I see no reason for that to change until the browser is obsolesced by something even better at fleecing the peasants.</comment>


Bitcoin rival Ethereum climbed 1000% in 3 months, crossing $1B in value at times - <AUTHOR> http://www.nytimes.com/2016/03/28/business/dealbook/ethereum-a-virtual-currency-enables-transactions-that-rival-bitcoins.html <comment><USER2> "Value", you say. I say, "a new trap for the greedy".</comment>


The CumEx-Files – How Europe's taxpayers have been swindled of €55B - <AUTHOR> https://cumex-files.com/en/ <comment> raffael-vogler correctiv.org is producing phantastic investigative journalism on a regular basis. one of their most important revelations recently was about a pharmacist who was selling heavily diluted cytostatic agents for chemo therapy. several people died because of this [1].

really awesome about correctiv is that they not just release their findings - they really make sure that something is going to be done about it. for example the government didn't do much about above mentioned case - they didn't even bother to inform the patients. so correctiv rented a shop in that town (Bottrop) where people could inform themselves about the matter.

if you want to support them: [https://correctiv.org/ueber-uns/#unterstuetzen- sie-unabhaeng...](https://correctiv.org/ueber-uns/#unterstuetzen-sie- unabhaengigen-journalismus).

the one thing I find most concerning about these kind of revelations is that it seems that journalism is more and more responsible for work police should be doing.

[1]: [https://correctiv.org/ruhr/alte-apotheke/2018/08/10/trotz- an...](https://correctiv.org/ruhr/alte-apotheke/2018/08/10/trotz- angekuendigter-kontrollen-maengel-und-unterdosierung-bei-krebsmedikamenten-in- nrw)

<comment><USER3> > _it seems that journalism is more and more responsible for work police > should be doing_

I think this echoes a lot of _sentiment_ , if perhaps without concrete evidence, across the world.

How can we solve this?

<comment><USER4> For people in "democratic" countries, get involved in civic duties. Register to vote, stay informed, volunteer to canvass and spread the word for campaigns. I donate monthly to causes I care about supporting. Corruption reform has taken place through these routes.

Edit-pedantry

<comment><USER5> _" For people in democratic republic countries"_

So obviously people from the UK, Norway, Netherlands, and Spain should not get involved /facepalm

<comment><USER6> First we have to address our ridiculously outdated structure and actually government sanctioned class system.

Having a queen and a ridiculously nationalist political parties has to be the most embarrassing parts of being British.

God (lol) divinely gives power to the queen (lol) through birthrite (lol) and we are her subjects (lol).

It is so deeply offensive that I am meant to he her slave, and its shocking how much idiots dont think it matters.

<comment><USER7> youre not her slave or subject really though are you? you havent been scrubbing her shoes or done anything at the request of the royal entourage im guessing. shes just a placeholder for tradition and has no say in anything. so really, it doesnt matter. stop getting your knickers in a twist over something so unimportant and irrelevant

</comment></comment></comment></comment></comment></comment><comment><USER8> It would be nice if they could cut to the chase instead of playing pretend Dostoyevski.

<comment><USER9> To be fair, the journalists put a lot of effort and money into this story. I think they should be allowed to tell the story as they see fit.

I'm sure the key points will be hashed and rehashed until many of the type of article you want are all over the internet.

<comment><USER10> Sure, but do they also want their story to be read by as many people as possible?

</comment></comment></comment><comment><USER11> _"Tax payers have lost up to €2 billion, that's nearly €350,000 for every Danish man, woman and child."_

You sure about that math, cumex-files?

<comment><USER12> Possibly confusion by someone who's used to the long scale? In Danish, as in most non-English European languages, the cognate of "billion" means trillion (10^12).

<comment><USER8> > in most non-English European languages

i dont think that's true

<comment><USER12> [https://en.wikipedia.org/wiki/Long_and_short_scales#Long_sca...](https://en.wikipedia.org/wiki/Long_and_short_scales#Long_scale_users)

The UK is the only place in Europe where "billion" means 10^9; in Eastern European languages, there simply isn't an equivalent word, and everywhere else it means 10^12.

<comment><USER13> An equivalent word for what? Poland is an EE language and has milion, miliard, bilion, biliard, etc.

</comment></comment></comment></comment></comment><comment><USER14> The German government did know about this stuff I think from 2002 or 2001 on, but still did not stop it until around 2012 in Germany and did not warn other countries, so it went on in those.

I just can not understand, how the government of my country could work this way. It really borders to actively supporting this scam.

In my opinion, not only the people that have done this (including many banks!), but also responsible persons in the government or ministries should take responsibilities.

But in Germany, if you are big enough or in government, you can do nearly everything without effects.

Banks already have looted the people of many countries in 2008/2009.

<comment><USER15> > But in Germany, if you are big enough or in government, you can do nearly > everything without effects.

While I sadly agree, I would like to point out that this is true of many countries.

<comment><USER14> I wanted to speak only for my own country, while I sadly think, I must agree.

</comment></comment></comment><comment><USER16> This reminds me of the way most application developers aren't security experts, and it's taken decades with a lot of very public hacks for awareness about the risks to be spread and for a set of security practices and middleware to evolve (hashed & salted passwords, CSRF mitigation, input sanitation, etc.), to make it feasible for normal developers to create reasonably secure applications. It seems something similar needs to happen in tax administration (and tax law) to make tax systems that are not exploitable. Maybe a new class of white-hats to "pen-test" the tax systems using loopholes and shell companies instead of 0-days and scanners?

<comment><USER17> The issue is that the tax system is a political/economic construct - <USER2> loopholes will take a very long time to be fixed. In the meantime, the white hat tax researchers have shown everyone else how to game the system.

</comment></comment><comment><USER18> There's a previous discussion for a NY Times article here: [https://news.ycombinator.com/item?id=18149831](https://news.ycombinator.com/item?id=18149831)

<comment><USER19> That NYT article was a lot better for understanding what was happening. I recommend it over the website here, even though it looks at Denmark instead of the whole EU.

</comment></comment><comment><USER20> Great journalism by FollowTheMoney.( with 12 other countries) Journalism the way it should be. Independent journalism payed by sponsors. [https://www.ftm.nl/](https://www.ftm.nl/) , if you are dutch, you should sponsor them to.

<comment><USER21> Yikes, that site needs an epilepsy warning. :(

</comment></comment><comment><USER22> I'm sorry, but what an unfortunate name.

<comment><USER23> Knowing bankers' humour, it's probably anything but.

</comment></comment><comment><USER24> [https://www.nytimes.com/2018/10/05/business/denmark-skat- tax...](https://www.nytimes.com/2018/10/05/business/denmark-skat-tax- scandal.html)

[https://news.ycombinator.com/item?id=18149831](https://news.ycombinator.com/item?id=18149831)

</comment><comment><USER25> TL;DR In the old days when space on paper was a limitation, journalism was about squeezing essence of the story in as few words as possible. Instead they have come up with some sort of graphical novel.

</comment><comment><USER26> This article is very hard to follow to figure out what has actually happened or what CumEx is.

In the beginning of the article is a rough description of the trade in question:

> Cum-ex – this is the name German media have given to this scam. > Internationally the different variants of these trades are known as dividend > arbitrage.

> Cum-ex and its variant cum-cum were highly complex share deals with no > economic purpose other than to receive tax 'reimbursements' from the state – > but for tax that had never in fact been paid. This is how it went. The > participants would lend each other shares of major corporations, creating > the appearance for the tax authorities that there were two owners of the > shares when in fact there was only one. The bank which settled the trades > would then issue a 'confirmation' to the investor that tax on dividend > payment had been paid to the tax office – when in fact it had not. With this > confirmation in hand, the investors were then 'reimbursed' by the state. > It's a bit like parents claiming child benefit for two – or more – children > when there is only one child in the family.

Late in the article we get a description of the origin of the trade:

> The money machine

> According to Frey, an equity trader at a US investment bank came across the > trade accidentally. He had bought shares that were delivered four days > later. This interval covered the dividend payment day of the company whose > shares he had purchased. This profit is taxed in the domicile of the company > (say, Germany). German shareholders can ask for this tax to be reimbursed > because they have already paid corporation tax.

> The trader suddenly realised he had this tax payable in his book without > actually owning the shares. The amount was £50 million. It was a very large > trade.

> The trader wanted to get rid of these funds that were not his. He approached > the seller of the shares who had also been reimbursed his tax. The bank's > legal department sought professional tax advice to find out how to return > the money to the tax office. The answer came back: "You can keep it."

> There is no law that prohibits a multiple tax payout, they said. And if > something is not explicitly prohibited, it is legal, the tax advisors > argued. The trader kept the money. And because the tax reimbursement > happened automatically, the scheme could be repeated time and again.

> All you needed was enough funds to trade the shares for a few days around > dividend payment date. Or you could even just borrow the shares.

Following "dividend arbitrage", there are a couple of other articles that talk about it, Bloomberg [1] and ProPublica [2], though it's hard to tell if they're talking about the same thing or an older version of the scheme. In Denmark, where there is the most evidence of reimbursement for unpaid taxes, it looks like the investigations date to 2015 [3].

[1] [https://www.bloomberg.com/news/articles/2018-05-18/denmark-t...](https://www.bloomberg.com/news/articles/2018-05-18/denmark- tax-collection-agency-sues-in-new-york-over-refund-scam)

[2] [https://www.propublica.org/article/denmark-is-big-victim- of-...](https://www.propublica.org/article/denmark-is-big-victim-of-wall- street-tax-avoidance-deals)

[3] [https://www.thelocal.dk/20150925/danish-tax-authority- cleans...](https://www.thelocal.dk/20150925/danish-tax-authority-cleans-up- after-scandals)

<comment><USER27> Thank you very much for this. This should be the opening of the article. I don't know why articles start like novels. With so much information being published nowadays, I would think the start of the article would include a summary/abstract to help the reader decide to dedicate the time to read the entire article.

</comment></comment><comment><USER28> The website could not be worse for mobile. There's a bar at the top, at the bottom, the address bar won't collapse, and to top it all off you can't use reader mode to fix it.

</comment><comment><USER29> Is something like this also going on in the US? US tax laws are probably just as complicated as European ones.

</comment><comment><USER30> So, they wrote "UBS drive"... is that a typo of USB, or did they get a leak from that bank?

</comment><comment><USER31> tl;dr; People asked for task refund on tax they didn't pay.

</comment><comment><USER32> TLDR

(saved for later reading)

In my understanding of reality, it's "business as usual".

</comment><comment><USER33> European taxpayers have been swindled of much more at the moment they paid their taxes. Who will later steal it once more from the thieves isn't really that interesting.

</comment><comment><USER34> Compliance are for small-medium Business & for common people; once a Business or a person grows too big to fail, paying the fines or bribing the legislators is the common route in most parts of the world.

I've anguished over this for years and have learned to accept it, depending upon where you live; this comment might sound entirely absurd.

<comment><USER35> If GDPR killed a startup it probably wasn't something worth keeping. Being compliant is sooo easy for small companies, it's mostly just about not being a dick about privacy.

And I have no idea why you thought bringing this up was relevant.

</comment></comment><comment><USER36> The missing transparancy disclaimer: "The Cumex files" is headed by "Correctiv", a german based "journalist network" which receives large parts of its funding by german goverment organizations and/or organizations which have close gov connections. But: the german goverment itself was aware of this scheme since at least 2002.

Also: this is a drop in the ocean compared to EU-internal tax loop holes and tax havens such as Luxembourg.

<comment><USER37> A disclaimer implies there is something to disclaim, such as a financial conflict of interest - what reason for a disclaimer are you imagining?

Besides, they literally have a link to a page with detailed financial information, including every organization that gave them more than 1000 EUR to them.

Most of their funding in 2017 came from private parties not affiliated with any government. I can't find any numbers for 2018, which is a shame.

[https://correctiv.org/en/about-us/](https://correctiv.org/en/about-us/)

<comment><USER8> The article may for example be intentionally be silent on inefficiency/misbehavior of tax authorities.

<comment><USER38> Your conspiracy seems rather incompetent if they chose to use their money to silence their critics on some aspects, _considering they financed that very investigation in the first place_.</comment></comment></comment></comment>


Apps, made better by everyone - <AUTHOR> http://assemblymade.tumblr.com/post/64965250674/apps-made-better-by-everyone <comment><USER2> It's a very interesting idea - so much so I can't think of anything to compare it to directly. It's like github, but instead of contributing to a repository, you're contributing to a running operation?

One thing I'm unclear about: how do you handle disagreements/forking? As in, I want to add a feature I need, but can't get it greenlit, can I easily run the app elsewhere?

Anyway, I'm interested to see how it turns out. Valve's structure is based on similar principles, so there's definitely something there.

[http://blogs.valvesoftware.com/economics/why-valve-or- what-d...](http://blogs.valvesoftware.com/economics/why-valve-or-what-do-we- need-corporations-for-and-how-does-valves-management-structure-fit-into- todays-corporate-world/)

<comment><USER3> Thanks, regarding disagreements, this is from our FAQ[1]

 _The Assembly platform is intended to allow everyone to vote and influence the direction of an app. Assembly also actively surfaces key metrics so all decisions are data driven and can even be reevaluated and rolled back later when more data is available. In the event the community hasn 't come to a clear direction and the data is inconclusive, the core team will be left to mediate disputes and decide on an outcome._

[1] [https://assemblymade.com/help/general#general-7](https://assemblymade.com/help/general#general-7)

<comment><USER4> Cool idea but this sounds a lot like design by committee. For end-user apps, there's nothing like focused design leadership to drive cohesive product decisions.

<comment><USER3> Our goal is to mirror as much as possible the collaboration process that open source uses to build better libraries then proprietary ones. Each product has a core team that will help lead the direction. You can read more about it on the FAQ:

[https://assemblymade.com/help/general#general-6](https://assemblymade.com/help/general#general-6)

<comment><USER5> Sounds like a bunch of "core" people could get open source contributors, then muscle the votes so no one gets paid.

</comment></comment></comment></comment></comment><comment><USER6> Its a great idea - but the terms are horrible. From my understanding Assembly made own the rights to the software and a pretty big stake in application.

The article talks about forking code, contributing to open source but goes directly against it.

[https://assemblymade.com/tos](https://assemblymade.com/tos)

<comment><AUTHOR> You're granting us an exclusive commercial license (not assigning your IP). We ask for that license so we can ensure that the other contributors who have worked on a project get paid.

We've decided to distribute the code with a modified-BSD license. We're open to discussing using different licenses but we've erred on the site of safety (for now). It'll be an easy change to make in the future when the risk/reward tradeoff of doing so is better known.

BTW, all our legal stuff is on on GitHub: [https://github.com/assemblymade/legal](https://github.com/assemblymade/legal) It's a work in progress :)

<comment><USER7> The FAQ says otherwise about the IP...

> To do this, Assembly must keep and manage all intellectual property derived > from Assembly apps. In exchange for that ownership, we give you perpetual > income based on the extent of your contribution to all projects you work on.

<comment><USER6> This was my take away as well

</comment></comment></comment></comment><comment><USER8> I spoke at length with these guys last night. My takeaway is that this isn't something I personally would get involved in.

First and foremost because I have a preference for starting my own projects independently as opposed to signing on with Assembly; for a number of reasons, chief among them is arguably personal preference and perhaps a bit of an entrepreneurial streak. I also think there's a potentiality, as open source continues to grow in popularity, for corporate-funded projects to be more alluring given that they provide a steady paycheck and benefits if you work for the company. For example, I work on an open source project which was initially an internal project developed for my employer and later released to the public. Today we maintain the codebase and in a sense I am paid to do that particular bit of open source work (I don't exclusively work on that, of course). Maybe this isn't a fair comparison, but I wouldn't give up my day job, which affords some of the benefits Assembly is ostensibly offering (get paid to do open source), or exchange the free time I spend on my own projects for this kind of stake sharing in a project or product...at least not yet.

On the other hand, this might be exactly what some people are looking to do in their free time: maybe you don't want to start your own company or you want to spend time in open source but prefer to get paid for it and your employer has no intention of helping you scratch that itch. However, given that last comment in particular, I really wonder if money is the proper motivating factor for so much of what the community has come to mean? Certainly the prestige of working on a popular or important project has historically been far more valuable than monetary compensation (and can even lead to monetary compensation these days, if a savvy employer is involved and happens to notice you're a Linux kernel committer or some such).

It's an interesting idea, that I'm sure of and I'm wishing these guys the best of luck with it! While I may not be their target audience, it does seem like there could be something here. So here's to hoping it develops into something awesome.

</comment><comment><USER9> These are all problems (email client, better support app, better mailing list) many of us on HN fantasise about but each has a whole bunch of schleps associated with it. The motivation to jump through all the loops is tempered by pragmatism that sets in after the first few hours.

This is an interesting way of attacking the problem. Some thoughts:

1\. Community will be attracted / restricted by the platform.

2\. There is too much fatigue out there, as there are so many such "ideas" competing for mind-space.

3\. SAAS based products for small businesses, freelancers has become a kind of a cottage industry with limited scalability. I am doubtful how much revenue this can generate.

<comment><USER3> Good comments. A few thoughts...

We only kickoff building one app a month.

 _1.Community will be attracted / restricted by the platform._

We agree and realize helping the community grow as a core responsibility of assembly.

 _2\. There is too much fatigue out there, as there are so many such "ideas" competing for mind-space._

We've thought a lot about this too. These are just of few of the initial app ideas we received. We curate all the new ideas that come in and work with the submitters on the promising ones before putting them up.

 _3\. SAAS based products for small businesses, freelancers has become a kind of a cottage industry with limited scalability. I am doubtful how much revenue this can generate._

I believe some the current app ideas are attacking larger opportunities, for example support-foo.. its proprietary competition would be a Zendesk. "Zendesk's fiscal 2012 revenue will be approximately $30 million"[1]

[1] [http://www.pehub.com/2012/11/29/zendesk-ready-2013-ipo- sourc...](http://www.pehub.com/2012/11/29/zendesk-ready-2013-ipo-sources/)

<comment><USER5> 1\. this is a big responsiblity. Are you really signed up for this?

2\. You curate the ideas? Doesn't sound very open to me. What about voting? How can you make this more democratic?

3\. I'm not convinced these projects could gain traction against a dedicated team of people lead by experienced people in the industry, paid a full time salary, with the sole purpose of making a profit. I would imagine that the open-source "everyone gets paid" thing is where this idea will fall flat on its face. Not sure it will get there though, because this process has to produce an app that generates revenue above operating costs first.

</comment></comment></comment><comment><USER10> Can a non-technical person contribute and idea and watch other people build it if it gets chosen?

Is this an "idea sourcing" engine or more "crowdsourcing developers without needing to join a full startup"?

<comment><USER11> Non-technical people can definitely contribute to the apps. For one if it's their idea, they get an immediate stake in future profits. There is also a lot of marketing and strategy work that goes into any successful product. The community around each product will vote the relative merits of each contribution. Basically, if someone submits work that is deemed good, they will receive a stake in profits.

In terms of where it lies on the idea sourcing to building spectrum, I would say it's definitely leaning towards building successful products. There's no shortage of good ideas floating around, we want to help organise people together to build great products and push those products to succeed.

</comment></comment><comment><USER12> Very much reminds me of Quirky for Apps -- AFAIK Quirky is doing really well. Congrats on the launch guys!

</comment><comment><USER13> If Support-Foo is going to be open source, and as per its description " _Instead of charging per-seat, it would charge by volume of support._ ", then why does the Enterprise option say " _1 year license_ to run behind the firewall with unlimited support and agents" ?

Is it open-source, and you need a license to run it behind a firewall?

<comment><USER11> To ensure collaboration is easy the code is open-source. To ensure contributors get paid for their work we'll run a hosted version and allow companies to run it themselves with a commercial license.

<comment><USER14> I stand corrected - Now I see it is like developing AGPL products by a group of individuals/community. Interesting concept, reminds me of an idea pitched to me few years back.

</comment></comment></comment><comment><USER15> Ah, almost communism except for the meritocracy part. Not sure why the Valley people are so into meritocracy....

<comment><USER16> The less constrained by basic needs people are, the more important the social desires, like acknowlegement, cooperation, sharing and so on become. There is plenty of cach to go around in software, hence people act a lot less based on purely selfish, materialistic motives.

<comment><USER17> I think you misread "meritocracy" as a good thing. Meritocracy is pretty much Ayn Rand's ideal society: the truly talented, superior people rise to the top and dominate the lesser. This is an uber-capitalist notion: the ubermensch pretty much can't be nice to inferiors, because that opens the door for cronyism, nepotism, etc.

By contrast, communism would be the ultimate expression of sharing, cooperation, etc. but it ignores people's skill in the distribution of value. The old maxim, "from each according to ability, to each according to need" means that someone who is paralyzed and (would have) massive medical bills receives free treatment, food, etc. to stay alive. Obviously this comes from more "skilled" people - doctors - who in a meritocracy would instead extract the maximum value from their skills.

</comment></comment></comment><comment><USER18> Will Assembly itself be open source?

</comment><comment><USER19> Neat idea, I like this very much.</comment>


Ask HN: What job is both technical and functional? - <AUTHOR> Hello HN,
I am graduating soon and I don't want to be a full-time dev but I don't want to be fully business-oriented either.
What kind of jobs would be good for a profile like mine ?
I have both a good technical  (lots of projects in multiple languages/frameworks) and a good functional background (PM internships for about 1 year).
I am afraid that my profile is too much of a jack-of-all-trades master of none type of thing.
Thank you. <comment><USER2> You could fit well as a technical co-founder if you are willing to get on that boat ride.</comment>


The New York Times Had a Mistake on Its Front Page for More Than a Century - <AUTHOR> http://www.theatlantic.com/technology/archive/2014/01/the-em-new-york-times-em-had-a-mistake-on-its-front-page-every-day-for-more-than-a-century/283076/?utm_content=buffer30925&utm_source=twitter.com <comment><USER2> uh oh, so now for each issue number 51,254 through 51,753, there exist two printed issues bearing that number.

If a programmer had done it, she would at least have had the decency to add a 'b' to the second printed 51,254 etc until they were caught up again.

</comment><comment><USER3> This just proves how some things just don't get followed up on (from the p.o.v. of a human time-frame of 30-40 years, which's how long one _might_ work for a given company in the 20th century)

</comment><comment><USER4> _Everybody_ knows they should have used a database sequence to generate the issue number. Those database administrators in the 1890's were _so_ lame.</comment>


Modern and simple clientside-solution-only to add feedback on your site - <AUTHOR> http://getsomefeedback.appspot.com

<comment><AUTHOR> With less than 100 lines of javascript you can add a feedback button to your site and read the feedback on the serverside. The code is free (ready to be hacked) and stored on github.</comment>


Collections-C, generic data structures for C - <AUTHOR> https://github.com/srdja/Collections-C <comment><USER2> I try and plug [http://concurrencykit.org/](http://concurrencykit.org/) whenever I see someone looking for something like this. It's built around providing portable atomic intrinsics for parallel code, but the data structures are also very well done and work just as nicely for single threaded code.

<comment><USER3> Yes, ck and preshing [https://github.com/preshing/junction](https://github.com/preshing/junction) are state of the art. This one really not.

</comment></comment><comment><USER4> Nice, but it's rather naive and through that - needlessly wasteful.

It's C.

Why on Earth you'd want to allocate a separate list node for each piece of data when you can embed this node directly into the data and then use container_of or similar offsetof() derivative to get a pointer to the data by a pointer to a list item? Saves you _at least_ sizeof(void*) per item and eliminates a chance of list_add ever failing among other things.

The same goes for custom allocators - why would you drag around pointers to malloc, calloc and free, when all you need is just a pointer to realloc?

This sort of thing. The code is nice, but it's not how one would write a container library after few years of hands-on C experience.

<comment><USER5> _allocate a separate list node for each piece of data_

So many programmers don't even consider "overhead" of data when writing things. But, most of the time it doesn't matter. Do you need a list of ten things? Great. Do whatever. Do you need a list of a billion things? Then you need to rethink everything from the bottom up.

 _when all you need is just a pointer to realloc_

Wrong! [https://github.com/Tarsnap/libcperciva/commit/cabe5fca76f6c3...](https://github.com/Tarsnap/libcperciva/commit/cabe5fca76f6c38f872ea4a5967458e6f3bfe054)

<comment><USER6> > So many programmers don't even consider "overhead" of data when writing > things.

Because they're using managed languages where the amount of overhead per object can't be reduced to zero. And also because, in exchange for that overhead, they get other benefits, like compacting garbage collection. But you don't get this in C.

</comment></comment></comment><comment><USER7> A quick look shows this is storing void* pointers only. My excitement was quickly over as I was expecting something with _Generic macros or ability to manage memory for any type.

[https://github.com/srdja/Collections-C/blob/master/src/hasht...](https://github.com/srdja/Collections-C/blob/master/src/hashtable.h) shows the container is manually configurable. Look at the defines at the bottom. This would mean the container file source-header pair, would have to be duplicated for every type, which is somewhat manageable.

Why isn't this written in the readme?

<comment><USER8> <shameless self promotion> Take a look at this instead. Work started on this before C-generics came about, so there is pretty heavy macro usage, but all data structures are type safe: [https://github.com/mgrosvenor/libchaste](https://github.com/mgrosvenor/libchaste)

<comment><USER7> I see you use C macro templates. I have been experimenting with containers that use those. The advantages are speed and full type safety, and disadvantages are long compilations times (which have to be done only once though), the need to define a new template for every type in (only one) separate file, code bloat, and somewhat long function names (I don't use member function pointers).

I'm not sure if all that is worth it.

<comment><USER8> I've not noticed the compile time increase to be honest. But I have noticed the type safety. A few times it has saved me from bugs that would have taken days to find if I was using void* casts. In my world (mostly high perf networking) I'm happy to pay a (small ~= unnoticeable) compile time cost if I get both safety and performance.

To make it more user friendly, I've provided (yet more) macros to make defining new types super easy. Using the macros does not necessarily involve adding a separate file, although the code is much cleaner if you do. And I don't have anything against adding extra files. There's almost no cost to me. I often group a couple of vectors or linked lists into a single .c/.h file pair to keep things manageable.

The code bloat you get is on par with using C++ templates. In fact, I'd say that it is probably better because the type safe macro's all devolve to a void* underlying implementation rather than generating separate instances. So it's pretty thin. You can always throw away the standard types list that I provide so that you don't have to pay for anything you don't use. And if you really want to, you can interface to the void* underlying implementation directly, loose the indirection costs, the function pointers and the macro costs. Basically, you can choose which world you want to live in, or live in both at the same time.

The long function names are handled by macros again. And since i used function pointer indirection you almost never see them. The costs with this sort of thing are minimal. A typical invocation looks something like

      CH_VECTOR(MYVECCLASS)* myvec =  NEW_CH_VECTOR(MYVECCLASS);
      myvec->append(myvec,object);

There are certainly tradeoffs, the implementation is not nearly as mature as I'd like and debugging problems inside the containers is a HUGE PITA. But in my experience it lets me kee the benefits of working in C (can pull inside the kernel, can port to different machines, easy control over memory and performance) and gives me the flexibility of doing higher level things when I want.

</comment></comment></comment></comment><comment><USER9> Would be nice to have parallel structures like "Intel threading building blocks" provides.

[https://en.m.wikipedia.org/wiki/Threading_Building_Blocks](https://en.m.wikipedia.org/wiki/Threading_Building_Blocks)

I recommend this book to understand such structures:

[https://www.goodreads.com/book/show/14788830-structured- para...](https://www.goodreads.com/book/show/14788830-structured-parallel- programming)

<comment><USER10> I'll definitely look into it.

</comment></comment><comment><USER10> Hello everyone, I'm the author of this library. I was quite surprised to find it on the front page of HN! I must thank you for all the great feedback, it's been very helpful. I agree that it has rough edges and that it also lacks some useful features but I guess this is mostly because I was the only user of it.

I very much welcome your suggestions on how to make better and more useful. :)

</comment><comment><USER11> Kazlib: since 1996.

[http://git.savannah.gnu.org/cgit/kazlib.git/tree/](http://git.savannah.gnu.org/cgit/kazlib.git/tree/)

[http://www.kylheku.com/~kaz/kazlib.html](http://www.kylheku.com/~kaz/kazlib.html)

Used in e2fsck since 2002: [http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/commit/e2fs...](http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/commit/e2fsck/dict.c?id=838e773e7a6899cec10884ad6c3fdcdaef72b82b)

</comment><comment><USER12> klib [1] is another good one I recently came across. In fact, I'll just leave this great curated list of free software libraries right here:

[https://notabug.org/koz.ross/awesome-c](https://notabug.org/koz.ross/awesome-c)

[1] [https://github.com/attractivechaos/klib](https://github.com/attractivechaos/klib)

</comment><comment><USER8> <shameless self promotion> If you're interested in this sort of thing, take a look at [https://github.com/mgrosvenor/libchaste](https://github.com/mgrosvenor/libchaste). Work started on this before C-generics came about, so there is pretty heavy macro usage, but all data structures are type safe rather than the "cast to void*" approach which is common in this space. It's a bit less mature, but reasonably well covered by unit tests where it matters.

</comment><comment><USER13> I tried reading the documentation, which is awfully sparse, to see how to use the hash table and if it would be a good replacement for the current one in cyrus-imapd.

The destroy function in cyrus-imapd has both a destroy that takes a cleanup function for values, and an interator:

[https://github.com/brong/cyrus- imapd/blob/master/lib/hash.c](https://github.com/brong/cyrus- imapd/blob/master/lib/hash.c)

I couldn't see how to do either with this library until reading the source code I see you can set a mem_free at creation instead.

The documentation didn't really describe that, and the example is actively wrong.

I see from the code that there's a way to get the keys, from which you can do an external iterator. It's less efficient, but it works. You wouldn't know that from the documentation though, you have to read the source code.

<comment><USER14> Any chance you're going to submit a pull request to fix the documentation? I'd like to check this library out for use in a project, but I'm not sure I'd get so far as you have with regards to matching the documentation to the sources ..

</comment></comment><comment><USER15> From hashtable ([https://github.com/srdja/Collections-C/blob/master/src/hasht...](https://github.com/srdja/Collections-C/blob/master/src/hashtable.c#L58))

> HashTableConf htc;

Hold short, that structure is allocated from the stack and not via malloc? I'd expect that one to blow up after the second call to hashtable_new.

edit: seems like htc is immutable and the values copied over in hashtable_new_conf, but that's downright scary in case one forgets this semantic and accidentally uses htc for something.

</comment><comment><USER16> It looks like all collections store void pointers. I don't see any abstractions to help with pointer lifetimes, which remains the main problem I encounter when trying to write large programs in C that dynamically allocate memory.

<comment><USER17> I'm no expert here, just curious. I've seen this brought up a couple times now: what's wrong with void pointers? How else would you do this in C? If you wanted abstractions to help with pointer lifetimes wouldn't you just be better off using C++?

<comment><USER18> The limitation with void pointers is that it can only inline values <= the size of a pointer. If you have something larger then you need to allocate it separately which may have cache efficiency issues.

The main alternative, other than hardcoding an element type, is to use macros and pass the element type in the definition.

Sometimes you just don't have the option of a C++ compiler. Also, and this was a situation I was in recently, I needed a collection in a small area of my C code so it really didn't warrant a toolset change.

</comment></comment></comment><comment><USER19> Has this library been stress tested? I am interested in using this library for a spaceflight application, but reliability is paramount in our situation.

<comment><USER20> I stopped looking when I saw it doesn't check for malloc failure. I am going to say space flight is a no-go.

<comment> david-given But for this kind of application, wouldn't you just panic and do a soft restart on malloc failure anyway? Actually _recovering_ from an out-of-memory situation is incredibly fraught and unreliable; most of the realtime operating systems I've used don't even bother to try.

<comment><USER19> That depends on when a failure were to occur. If we have a failure while the spacecraft is en route to its destination, perhaps we can recover because we may have enough time.

If we have a failure during rendezvous with our target, it could be a very bad day.

<comment> david-given ...necropost, but:

You always need to be able to recover from a soft reboot, even during maneuvers; you're in a high radiation environment and any passing high energy particle or cosmic ray can trigger this.

</comment></comment></comment></comment></comment><comment><USER21> nice. I actually built something very similar a while ago. although I only supported lists, queue and stacks... [https://github.com/mellowcandle/liblist](https://github.com/mellowcandle/liblist)

</comment><comment><USER22> Something like this should be in standard C.

</comment><comment><USER23> Take that, Golang!!!!

J/K

</comment><comment><USER24> Honestly, why? Most of the time, you want to write C++, with exceptions, and the STL. You can make this kind of programming as robust as you want against memory allocation failure.

If you don't want to use this style of programming, for whatever reason, check out sys/queue.h. It's already on your system, if you're using some kind of Unix.

<comment><USER19> If you are using an RTOS (which many timing-critical applications run on), you should be worried about memory allocations happening under the hood.

If you don't have full control over when memory is being allocated/reallocated, your system is now non-deterministic.

With pure C, you can know exactly when those few extra instructions for resizing your dynamic array are going to happen.

<comment><USER6> Same in C++. There's `std::vector::reserve`, which grows the vector's underlying physical buffer, without logically adding any new elements. If you `reserve` enough capacity before inserting anything, it's even a `O(1)` operation.

<comment><USER19> Vector and possibly string have that. The vast majority of STL structures do not.

<comment><USER6> All containers from the C++ standard library (please don't call it STL, that's Stepanov's original library) can be parameterized by an allocator. You can use whatever allocation policy you like best. However, most people use the default allocator because it's good enough.

In any case, while C++ has lots of defects, "loss of control relative to what C gives you" isn't one of them.

<comment><USER25> (a bit of topic - but I'm humbly trying to learn more...) I've got zero experience writing allocators. Is there some common ones you use provided somewhere? Do you write your own? (in which case can you point me to where to learn to do that properly)

<comment><USER6> I don't write allocators myself, but Boost has a pool allocator library [[http://www.boost.org/doc/libs/1_60_0/libs/pool/doc/html/inde...](http://www.boost.org/doc/libs/1_60_0/libs/pool/doc/html/index.html)], which conforms to the Allocator concept defined in the standard library [[http://en.cppreference.com/w/cpp/concept/Allocator](http://en.cppreference.com/w/cpp/concept/Allocator)].

<comment><USER25> Thank you</comment></comment></comment></comment></comment></comment></comment></comment>