What I Learned from porting my projects to FreeBSD - <AUTHOR> https://github.com/shlomif/what-i-learned-from-porting-to-freebsd <comment><USER2> The author mentions to be unsatisfied with the solution to use symlinks for finding DocBook XSL files. The correct way to reference DocBook XSL stylesheets is to use the HTTP URL to the stylesheet, which will be looked up in the XML catalog of your system. This catalog file maps URLs to files on disk and is managed by your package manager.

You should also forbid your tools to access these URLs directly (--nonet), as it would be incredicly slow and you rather want your build to fail in this case instead of downloading on-demand.

      xsltproc --nonet http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl foobar.xml

If you prefer to work with files instead of passing long URLs on command line, use a small wrapper file to import the real stylesheet and pass that on command line instead of using the URL. The advantage is that you can also put additional <xsl:param> tags to customize the output right into this file.

      <?xml version='1.0' ?>
      <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
      <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl"/>
      <!-- put additional xsl:param here -->
      </xsl:stylesheet>

<comment><USER3> Isn't referencing something like "[http://docbook.sourceforge.net/release/xsl/current/manpages/...](http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl") wrong, because that refers to some unspecified version (note the "/current/" bit)?

</comment></comment><comment><USER4> If your makefiles use gnu-isms (which is a valid choice) then I would lean towards using GNUmakefile and have Makefile call gmake - and don't forget to use $(MAKE) for any recursion.

This is less fragile and requires less dependence on replacing make in the $PATH.

<comment><USER5> Could do all that, but FreeBSD _could_ also have GNU make as the standard "make". I know there's some "license purity" reason why they don't want to do that, but don't expect everyone else to work around your self-imposed problem.

<comment><USER6> isn't make older than gmake? it is normally gnu that adds extensions not compatible with the rest of the Unix world. making people believe sh == bash, make == gmake, m4 == gm4, and the list goes on for everything they touch.

<comment><USER7> But BSD make has extensions too. They're just different extensions.

</comment></comment></comment></comment><comment><USER8> For anyone interested, I'm providing FreeBSD CI services on sr.ht. We use it to test wlroots[0].

[https://builds.sr.ht/~sircmpwn/job/9348](https://builds.sr.ht/~sircmpwn/job/9348)

I'm also working on OpenBSD and NetBSD, other kernels, and non-x86 architectures. If anyone is interested in using this to make their software more portable, please let me know! Email in my profile.

[0] [https://github.com/swaywm/wlroots](https://github.com/swaywm/wlroots)

<comment><USER9> TravisCI has been asked repeatedly to provide FreeBSD as a build OS, and it doesn't appear they're interested in expanding beyond Linux/macOS on x86:

* [https://github.com/travis-ci/travis-ci/issues/1818](https://github.com/travis-ci/travis-ci/issues/1818) * [https://github.com/travis-ci/travis-ci/issues/6671](https://github.com/travis-ci/travis-ci/issues/6671) * [https://github.com/travis-ci/travis-ci/issues/5473](https://github.com/travis-ci/travis-ci/issues/5473)

Do you plan on providing Github integration? Providing other OSes and platforms (e.g. ARM64, ppc64el) would be really useful for testing low-level projects like .NET Core runtime, node.js / libuv, etc., and integrating with Github would make it really easy for people to start adding this to their existing projects.

If you do end up providing Github integration, consider listing a paid option for your service in the Github marketplace: [https://github.com/marketplace/category/continuous- integrati...](https://github.com/marketplace/category/continuous-integration)

<comment><USER8> I already provide Github integration, but it's not very polished. That's how wlroots gets built, for example:

[https://github.com/swaywm/wlroots/pull/1341](https://github.com/swaywm/wlroots/pull/1341)

(click "show all checks")

I may add it to the marketplace once it's open for public registration and more polished.

</comment></comment></comment><comment><USER10> Just wait till you discover FreeNAS, pfSense, and OpenBSD! A world of awesome, battle-tested software awaits once you join the BSD dark side.

<comment><USER11> pfSense is great for a prosumer router. What gets me about it is cleaning up the mess it creates in business use cases, as pfSense is designed with a mindset that the pro will always be there, ready to attach a screen at a moments notice when interfaces change or packages get updated. Running PHP as root also isn't great, I'm not sure how that passes in the context of HIPPA.

<comment><USER12> The HIPAA Technical Safeguards are compact, readable, and basic: [https://www.law.cornell.edu/cfr/text/45/164.312](https://www.law.cornell.edu/cfr/text/45/164.312)

<comment><USER11> Okay, but how does running one of the most commonly exploited languages as root pass any HIPAA audit? That was the question asked in my prior comment.

We ended up ripping out PFSense at a few medical practices due in part to this issue.

<comment><USER13> You seem to be under the impression that the management UI is on a public network. Ideally locked down to certain vlans.

The UI controls setting up the network and other services. Please explain how to do this without root access. (Write another process which runs as root and controls the settings and is talked to over a Unix socket actually isn't a bad idea, however, it is not void of its problems either.)

Also "most commonly exploited languages" is a bit of hyperbole, no? First, C probably takes that slot. Second, being one of the most common languages for web development makes it a target. Third, most php exploits are bad code, which, while easy to write in php (and c!), can be and is done in all languages.

Isn't the administrator interface on _any_ router essentially root access on said router? Do you complain that juniper or Cisco equipment is insecure because you can login?

BMCs (Baseboard management controllers) are something with very ... questionable ... security, yet network segregation is used to ensure its use securely. Given that many HIPAA complaint organizations such as AWS and GCP (Google Cloud Platform) I find it hard to believe that a management interface would disqualify something from HIPAA compliance.

Which part of the HIPAA audit did pfsense fail? Was it simply an abundance of caution" on your part? If so, what did you replace it with that didn't have a management or has a management interface with no bugs (hint: even Cisco and juniper have CVEs for the management interface)?

<comment><USER14> PHP makes it trivial to write bad code, and hard to write good code.

<comment><USER13> So does C?

Also, php in no way makes it hard to write good code, it's just easy not to.

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> Or just switch to Meson+Ninja [1][2] and enjoy all features of modern build systems.

[1] [https://mesonbuild.com/](https://mesonbuild.com/)

[2] [https://ninja-build.org/](https://ninja-build.org/)

<comment><USER16> In what sense isn't gnu make a modern build system?

<comment><USER17> Make is a much of a build system as C++ as you can call stat() and system() from it.

A modern build system by default should be able to provide utilities to make sure your build is correct and reproducible. Those features need to be coded into your Makefile and aren't available easily or by default.

If you need to code those rules, then you don't have a build system, just a way to run commands and possibly add some (usually poor) logic around them.

A typical example that most handcrafted Makefiles will fail is that changing a build flag should only rebuild the files affected. Most will either require a full clean (aka ignoring the flag change) or rebuild everything.

<comment><USER16> > A typical example that most handcrafted Makefiles will fail is that changing > a build flag should only rebuild the files affected.

If you change a build flag, how aren't all the files affected?

<comment><USER18> I've noticed a plethora of build options over the past decades. I keep hearing how they are all "better" than make.

Then to build one particular bit of software, there is a dependency upon a particular version of cmake, which you don't have.

Or you have to upgrade Maven. Or install some software you do not have by default on your environment.

I've never had to do that with make.

I've been told that other tools are better because the are simpler ... that is ... until you run into one of those aforementioned compatibility issues with the build tool.

This isn't an infrequent occurrence for me, I see lots of hardwiring for various packages that I don't have installed by default in some projects.

Then you get the gophers/rust folk, and their need to run on the most recently released kit. With all its undiscovered bugs. The gophers want to replace make with mage ... well, to be more correct, they want to replace every non-go based tool with one built in go, because ... go. A modern version of the insufferable pythonistas of years past.

Throughout this, I've been using and building with Make just fine. My make files do the heavy lifting in my projects. And I get a good laugh each time I hear "oh I have to fix my magefile/CMakeFile.txt/yadda yadda yadda".

As the great philosopher Inigo Montoya once opined ... you keep using that word [better]. I do not think it means what you think it means.

</comment></comment></comment></comment></comment><comment><USER19> Another great thing about FreeBSD is it's not too hard going the other way: Embedding FreeBSD is a robust choice, one that can take you quickly to market as it did for me and a GPS on golf cart project I did in the late 90s with it, busybox, and some valuable help from PHK on getting support for the weirdo LCD panel the suits picked (we had to turn the panel upside down in the cart, the viewing angle was atrocious).

</comment><comment> dis-sys "It is easier to port a shell than a shell script."

This is gold!

</comment><comment><USER20> I wish more VPS providers offered OpenBSD and FreeBSD. I remember using FreeBSD a lot when I was 12-17 just messing around and setting up servers, etc but eventually moved to Debian because VPS' at the time didn't really offer these that much (reliably.)

<comment><USER21> I've been running OpenBSD machines on Vultr for a little while, it's been good.

</comment></comment><comment><USER22> now you should try openbsd or netbsd, as they are even less tolerant of linux- isms

<comment><USER23> Given that Linux is the de facto standard, wouldn't it be more correct to describe the BSDisms as idiosyncrasies?

<comment><USER24> Which distro? Which libc? Which minimum kernel version? Which minimum version of GNU Make? Which _specific_ version of GCC or clang?

Linux isn't a static environment. The closest thing to static is POSIX, and by and large every Unix environment, including various Linux environments as well as BSD environments, asymptotically approach POSIX compliance.

If you want to maintain a project long-term (5+ years), attempting to minimize deviations from POSIX is a solid strategy in terms of avoiding bit rot and long-term maintenance burdens. Sometimes it's unavoidable, but the point is to weigh your options carefully and don't undervalue the benefit of POSIX compliance. If you want to maximize the chance that your software will compile and execute correctly on a Linux distro 5+ years from now, a good first step is making sure it builds and runs natively on some of the BSDs.

There's a trend to discount the value of POSIX and to even actively break POSIX compliance in a way that makes it very difficult to support both POSIX semantics and some feature du jure. Developers should be wary of those who do this because if such projects and their maintainers don't see any value in POSIX they're not likely to see value in the long-term maintenance and stability of whatever feature they're selling you on today.

Else thread somebody says that they see Linux as the new SunOS. I agree.[1] But where is SunOS today?

[1] Except that Sun put much more emphasis on backwards compatibility. The Linux _kernel_ _developers_ emphasize backward compatibility, but the distros don't, and if the distros rip something out then inevitably it gets removed from upstream. OTOH, while the kernel developers rightfully have said they won't compromise sane design for POSIX, it turns out that such situations have been _exceedingly_ rare and in general they take POSIX compliance seriously.

<comment><USER25> _maintainers don 't see any value in POSIX _

The problem is that POSIX only provides a tiny subset of the API surface that an application might need today. Just to give two random examples: how can an application inhibit system sleep or use a webcam? The best one often can do is rely on some widely-used library and hope that they (will continue to) support multiple platforms.

 _But where is SunOS today?_

Comparing apples and oranges. For a large part of its lifetime, SunOS was a proprietary UNIX that only worked with Sun hardware. If we include SunOS 5/Solaris, they open sourced Solaris way after Linux already had a stronghold in the market.

Linux is now so dominant in mobile phones, servers, network devices, and IoT, that even it will take much longer to disappear than SunOS.

<comment><USER26> The other problem is that POSIX is _horrible_. See eg:

\- [http://www.daemonology.net/blog/2011-12-17-POSIX-close-is- br...](http://www.daemonology.net/blog/2011-12-17-POSIX-close-is-broken.html) It's impossible to reliably _close a file_ if you have active signal handlers that might be triggered.

\- [https://www.sqlite.org/src/artifact/c230a7a24?ln=994-1081](https://www.sqlite.org/src/artifact/c230a7a24?ln=994-1081) (discussed at [https://news.ycombinator.com/item?id=17601581](https://news.ycombinator.com/item?id=17601581) "POSIX advisory locks are broken by design.")

\- Seemingly anything to do with terminal devices or job control. (Allocating ptys, sending control sequences like ^D or ^Z, adding processes to a group that will all recieve terminal signals together, etc.)

\- 'Basic' regular expressions (as in `echo baaar | grep 'a+' || echo WTF`).

\- The existence of hard links as anything beyond a destination cache for symlinks.

Most operating systems _have_ problems like these, but POSIX proceeds to enshrine them as unfixable 'features' rather than "DEPRECATED: DO NOT USE". (On the plus side, F_SETLK(W) and close seem likely to be fixed at some point and close doesn't tend to get maliciously exploited the way eg integer overflow does by C compilers.)

<comment><USER24> Every implementation of close, _except_ on HP/UX, will close the file descriptor before returning upon a signal. But POSIX has actually approved posix_close, which will guarantee the proper, desired semantics. See [http://austingroupbugs.net/view.php?id=529](http://austingroupbugs.net/view.php?id=529)

The semantics of POSIX advisory locks were inherited; they codified the most widely used existing implementation. The ergonomics suck, but they offer one distinct advantage: you can query the PID of the lock holder, something not possible when a lock can be inherited. This can be useful for PID file locks where you can query the PID directly rather than trying to write and read it from the PID file; there's no loaded gun lying around, although there's still the TOCTTOU race between querying and kill'ing. In any event, "file-private" advisory locks are likely to be standardized and are already implemented by both Linux and FreeBSD. See [http://austingroupbugs.net/view.php?id=768](http://austingroupbugs.net/view.php?id=768) The semantics are not coincidentally very similar to BSD flock, and the types similar to POSIX. Which is noteworthy because it's an example of how paying attention to POSIX and portability issues can help you triangulate the evolution of Linux interfaces down the road.

It's not like Linux is without its warts. The kernel's implementation of setuid & friends is per thread. That's not only horribly inconvenient semantics for 99% of use cases, it's a security nightmare. And glibc and musl must implement an obscenely complex dance to get process-wide, atomic behavior. There are also many legacy Linux interfaces that the project is committed to supporting because of its commitment to backwards compatibility. I don't understand the logic of pointing out all the anachronisms of POSIX (e.g. advisory locks) while ignoring the anachronisms of Linux.

I never said POSIX was perfect, and I'm not arguing to _only_ stick to POSIX. There's no substitute for using your own good judgment. I'm simply saying that too many people don't appreciate the benefits of POSIX and portability more generally, which are substantial. The benefits aren't just the standard itself or the ability to use an alternative OS like FreeBSD--if you didn't care before you're almost certainly never going to--but the fact that every Unix vendor _tracks_ the standard and, to a lesser extent, avoids gratuitous incompatibilities with other POSIX environments. Standardization signals important information about the stability of an interface, and the process of standardization channels the evolution of interfaces long before they become standardized (if ever). POSIX and the BSDs matter to Linux development; and they _should_ matter to Linux developers even if they'll never run code outside of a Linux environment.

It's also worth mentioning that Red Hat basically steers POSIX, now, judging by the Austin Group Bugs issue tracker. So while some teams are rather antagonistic toward POSIX (e.g. Poettering and systemd team), others put considerable effort into it.

</comment></comment></comment></comment></comment></comment><comment><USER27> Is there a jquery equivalent for shell scripting?

<comment><USER28> Quoting a quote from the article:

> Perl is portable shell

Which ironically I do use in this way but never formulated it in such a compact and witty way.

I found Perl to be available basically by default on every platform I could encounter, from AIX 3 to Windows (it comes along with Git for Windows, which gives you bash too).

</comment></comment><comment><USER29> FreeBSD is great! Even as a desktop. NVIDIA builds official drivers for FreeBSD. I dont know whats the status for newer AMD graphics card. Nvidia + Intel graphics also works very well.

There is a port system where users can build the packages from sourcecode on their own machines. Its +- like gentoo.

There is also a binary pkg system. It is faster to install since the packages are already built (binary).

To upgrade from minor versions ie. 11.1 to 11.2 it is very simple and well documented. Just see in the manual freebsd-update

There is native support for ZFS also which is great.

Virtualbox works very well, so its possible to install other OSes in virtualbox. VMware i dont think is supported.

</comment><comment><USER30> > FreeBSD's grep does not have a "-P" flag by default

(I continue to wonder what's stopping everyone from just ditching `grep` altogether and switching to `ag`/`rg`)

<comment><USER31> Why? They're not compatible and not a drop-in replacement.

They're also likely a little bit slower, especially on large datasets. It's really hard to beat GNU grep. (Which is famously 3 cycles/byte in the trivial case. Great exercise though.) But for the most part performance is secondary to feature partity.

<comment><USER32> FWIW rg is faster than gnu grep [https://github.com/BurntSushi/ripgrep#quick- examples-compari...](https://github.com/BurntSushi/ripgrep#quick-examples- comparing-tools)

<comment><USER31> Right, by "very hard to beat" I didn't mean to imply it was somehow impossible.

Looking at the whole benchmark that that page links to, the difference is within a few percent for the actual searching, but it is also the only software in the author's own benchmark that is even close. The other software that was mentioned in the comment above is some 5x worse.

Nobody is going to change the standard grep for performance reasons.

<comment><USER33> ripgrep author here.

It really depends on what you're searching. In some types of searches, GNU grep can get very very slow. The page you were linked to includes some benchmarks for that. In particular, cases where you're searching large amounts of non-ASCII (but UTF-8) text. There are some benchmarks for that case here: [https://blog.burntsushi.net/ripgrep/](https://blog.burntsushi.net/ripgrep/) specifically: [https://blog.burntsushi.net/ripgrep/#subtitles-no- literal](https://blog.burntsushi.net/ripgrep/#subtitles-no-literal)

Also, it's probably not about "feature parity" per se, but standardization. In terms of feature parity, there is very little that grep can do that, say, ripgrep cannot. But there is quite a bit that ripgrep can do that grep cannot do, mostly by design.

"replacing" grep with ripgrep has at least a dual meaning, and it is the source of unending miscommunication. In the one sense, I know plenty of people that have replaced grep with ripgrep (or whatever) in daily usage. This is a perfectly valid thing to do. In another sense, nobody is going to replace grep with ripgrep in a distribution because they almost certainly do not want to stop being POSIX compatible. That is, asking to "just replace" grep with ripgrep is equivalent to asking distributors to stop being POSIX compatible in exchange for some other feature that ripgrep provides. That question is a non- starter, but a lot of people either don't realize that or are confusing what it means to "replace" something.

<comment><USER34> Could ripgrep offer a POSIX compatible mode?

<comment><USER33> It "could" in the sense that it's of course technically possible. But it's a _ton_ of work, and it's not clear to me that it would actually be beneficial. GNU grep is doing just fine as far as I can tell at being a POSIX compatible grep.

ripgrep is split into libraries, so if someone wanted this, they could just go do it themselves. :-) It would actually be pretty easy to get something that _smells_ like POSIX. But the details make up a very long tail, and some of those tasks are fairly significant (supporting BRE syntax, supporting POSIX- style alternations, supporting POSIX locales).

</comment></comment></comment></comment></comment></comment></comment><comment><USER35> >Perl is portable shell — Guy Keren

Which still has many of the terrible problems of the shell, because its original design was an imitation of several different shell scripting languages.

If all you know is Perl and you're incapable of learning any other languages, or for some perverse reason you like the way Perl scripts look just as incomprehensible as shell scripts, and you're absolutely sure nobody else will ever need to look at or maintain your code, then by all means use Perl. But if you don't hate the people who will have to clean up after you or decipher and maintain what you're done, then please use Python or JavaScript instead of Perl or shell scripts.

<comment><USER36> > and you're absolutely sure nobody else will ever need to look at or maintain > your code

By "nobody else" you really mean "other people with the same mindset who aren't willing to invest some time in getting used to perl syntax". Thing is that modern javascript is just as incomprehensible to sysops/devops people who're not familiar with the new JS syntax. You come from one world and think that's the "normal", they come from the other and expect that everyone already knows perl as it is half bash, half C. And in the end it's really much more about how much time did you spend working in it, than in one language being so much clearer than the other.

<comment><USER35> Too many people have for too long treated Perl as way to blackmail their employers into not firing them, by developing an unmaintainable code base that nobody else can understand. Do you really want to be "that guy", or clean up after them yourself? (I say "that guy" because the Perl community is historically hostile to women, with the "hooters girls" at trade show booths, etc.)

[http://geekfeminism.wikia.com/wiki/Randal_Schwartz](http://geekfeminism.wikia.com/wiki/Randal_Schwartz)

"He's the Hooter's guy, right?"

[https://web.archive.org/web/20080328132126/https://www.oblom...](https://web.archive.org/web/20080328132126/https://www.oblomovka.com/entries/2004/07/28)

[http://blogs.perl.org/users/joe_mcmahon1/2012/08/why-im- cons...](http://blogs.perl.org/users/joe_mcmahon1/2012/08/why-im-considering- dropping-perlmonks.html)

And have you ever tried to hire a competent experienced Perl programmer? They're extremely hard to find, and very expensive, and usually would rather be working with some other language. Sure, incompetent ones are a dime a dozen, but hiring those and setting them loose just starts the vicious cycle again.

All of the competent Perl programmers have long since been hired up by companies desperately trying to find people qualified to work on their old toxic legacy code bases that they're stuck with. Like Booking.com for example.

And writing new code in Perl is insane. There's absolutely nothing special about Perl 5 or Perl 6 that solves any problems you can't easily solve in most other languages.

Perl's much larger problems totally overwhelm the minor conveniences from its "syntactic syrup of ipecac" that perversely appeals those few people who think saving a few keystrokes at the expense of readability, instead of spelling words out with letters instead of line-noise punctuation and acronyms, is the sole goal of software development.

Perl 6 is a joke, a slow moving parody of itself that missed the boat decades ago, and it's absolutely never going to catch up with JavaScript or Python.

If you really want to optimize your career for programming toxic legacy code that's too ugly for anyone else to touch, you should have learned COBOL before the Y2K "crisis". But in the long term, you might have regretted it:

[https://medium.com/@donhopkins/cobol- forever-1a49f7d28a39](https://medium.com/@donhopkins/cobol- forever-1a49f7d28a39)

<comment><USER18> Wow. Just wow. FUD. Pure and simple.

Perl is doing well, thank you. Perl6 is interesting, but I don't have a project for it yet. There are jobs in perl, there are needs, and we (perl devs) aren't appreciably more expensive than non-perl devs, though some of us may be better at negotiation than the dime-a-dozen developers in more "common" languages.

There is just so much that is wrong with the post above. Its actually sad.</comment></comment></comment></comment>


PayPal: 'Aggressive changes' coming to frozen funds policy - <AUTHOR> http://money.cnn.com/2013/01/21/technology/paypal-frozen-funds/ <comment><USER3> "We're at risk from upstarts in every sector of our business. Developers hate us."

"All hands on deck! We've got to get the communications team together and put out the best damn press release we've ever done."

"But we don't have anything to announce."

"Just announce that we'll be making an announcement soon. An aggressive announcement."

"Ok, I'll put it in with the cheque for our last batch of commercials - <USER2> should ensure we get prominent coverage and see off the likes of Stripe - I'd like to see them get an empty press release onto CNN.com this fast."

<comment><USER4> Close. The aggressive change they are making is, in fact, the press. IE Paypal is making aggressive changes (in how they communicate to the press that they think they've done nothing wrong)

<comment><USER5> To their credit, they didn't use the word "terrorist," once.

</comment></comment></comment><comment><USER6> To save everyone the trouble... This article is just a PR parrot piece, with no real substance or timelines beyond "aggressive changes" and "the next several months".

It just feels like a desperate attempt to convince potential clients not to go with competing services for a bit longer, like the new guy who took over at the top, showed up in person on a few on-line forums to say positive-sounding things, and then disappeared without trace.

Amusingly, the PR rep quoted in this article actually seems quite proud that when they screw up and freeze an innocent client's account and then demand a bunch of non-existent and inappropriate records to release the funds, the client won't be expected to submit them _in the mail_ any more.

<comment><USER5> What are good alternatives? I'm considering taking online payments for my freelancing work, but I'm gunshy that it could kill my cashflow without recourse if a company acted toward me like PayPal often does to others.

<comment><USER6> It depends a lot on where you are. You might find this HN discussion from a few hours ago interesting:

<http://news.ycombinator.com/item?id=5091069>

</comment></comment></comment><comment><USER7> I'd wager that most of the people you see bagging on PayPal have:

1) Never used them in a business capacity

2) Have only read horror stories

3) Take those stories at face value

The horror stories usually have an obvious, "duh" kind of reasoning behind them when you step back and think about it from PayPal's point of view. Big influx of sales out of nowhere? That's a flagging. Accepting money for some kind of charity? That's a flagging.

I'm very satisfied with their service. They work to protect your money, your customers' money, and their reputation. If you're an entrepreneur and you aren't sure what payment processor to go with, don't exclude PayPal from consideration.

<comment><USER8> I've been taking payments with PayPal for 13 years this June. I feel exactly the same. Not only has their service and support always been excellent for me, they're by far the most economical option, at first glance (the effective transaction rate is lower than any other 3rd party processor, or the 3 traditional merchant account providers I've used), and on closer scrutiny (the fraud screening and dispute resolution mean I keep more of the money I get paid through PayPal than by credit card directly).

<comment><USER9> I agree with this sentiment for having over 4 years of heavy use. They have plenty of things that need updating (slow history, API sucks), but at least I get great support if I have trouble and need to call. The 2.2% fees aren't bad; not a great rate either, but it's keeping me from moving to Stripe, which has worse fees. Note that I have a traditional ecommerce store who sells real physical items.

</comment></comment></comment><comment><USER10> I find this quote from the article ironic:

"Nayar said he can't go into specifics about what will change, but transparency is a major focus."

<comment><USER11> Having dealt (attempted to deal) with PayPal after my 10 year old account was randomly frozen, I have come to the conclusion the PayPal is run by robots. Poorly programmed robots.

</comment></comment><comment><USER12> This is great news.

Not because I care at all about PayPal's practices anymore, but because it might mean that enough people have joined the backlash and boycott to make PayPal take notice.

</comment><comment><USER13> This is literally more than a decade overdue. The very first "sucks" site I ever heard of was none other than paypalsucks.com way back in the early 2000s, and even at that time it heavily documented this and many other issues with PayPal's service.

Awesome response time guys!

</comment><comment><USER14> I feel like we've heard this all before countless times. Paypal has been poorly managed for a very long time. Their dictator like ways of, "We're freezing your account and keeping your money unless you send us all of your receipts proving all transactions are legitimate" have screwed so many over the years. I think it's a little too late to repair Paypal's image, the customer support staff are the least human like support staff I've ever dealt with. All responses from Paypal customer support are copied and pasted, 99% of the time ignoring what you've actually typed out. Maybe they should fix that problem while they're there.

I seriously doubt these aggressive changes will change anything, if they do it will probably only reduce the number of incorrectly frozen accounts by a small percentage. Paypal will always be brought down by their uneducated, non- compassionate customer support staff and their horrible policies. While my experience with them on a business level has been somewhat limited (I do have a business premier pro account) and I myself haven't had any serious issues, I've been through the frozen funds thing before but came out unscathed although after digging through the crappy support and finally getting someone with enough drive and compassionate to ensure my problems were resolved.

The number one problem isn't the policies, because a lot of people have nothing but good experiences with Paypal it's their staff, the people on the front-line who ensure your queries are appropriately directed and brought to the attention of the right people internally to solve your problem, these staff are misinterpreting policies and not listening. Another tolerable problem is Paypal's API: it feels archaic and pretty poor in comparison to other payment competitors with much nicer JSON API's and support for Javascript payments processing like Square. Paypal really need to step up their game, they've still got a chance considering the deep integration into Gumtree and eBay.

</comment><comment><USER15> What about their arbitrary policies about freezing certain types of businesses' funds or not allowing them to operate using Paypal because they don't like them - like say if you sell a certain type of books?

</comment><comment><USER16> Too little too late. Bitcoin already won (and for those naysayers that think Bitcoin will never win, theres at least three popular Paypal clones out there too)

<comment><USER17> I'm not going to say that Bitcoin will never win, but why do you think Bitcoin has already won? I've never even seen it as an available payment method on a site, and people employed outside of the tech industry generally haven't heard of it.

<comment><USER18> Three of the top 1000 websites in the world started accepting bitcoins in the past few months--most notably Wordpress. [http://www.thebitcointrader.com/2011/12/bitcoin-bounty- ladde...](http://www.thebitcointrader.com/2011/12/bitcoin-bounty-ladder.html)

Thousands of other sites and hundreds of real life locations accept bitcoins-- many exclusively. I get unsolicited questions about Bitcoin from non-tech people who see my posts about it just about every day. The coming Bitcoin update is specifically meant to make Bitcoin much more non-tech friendly. I greatly anticipate swaths of non-tech users buying in very soon.

I think it's a little early to say Bitcoin has "won" against Paypal when the BTC market cap only just recently broke $200 Million USD. But it is certainly here to stay. Bitcoin's exponentially increasing global adoption rate all but ensures that it will be around for a long time to come.

</comment></comment></comment><comment><USER19> so, Stripe is eating their lunch then...

<comment><USER20> Too little too late for Paypal.

This was always the most pressing problem they've always continued to ignore and now their hubris is going to hurt them.

I hope Stripe buries them and I hope this case is taught in business schools the world over.

</comment></comment><comment><USER21> It's about time. I do wonder to what extent the brand damage already done will be a drag on their usage numbers.

</comment><comment><USER22> The one thing they don't say in this article is that they will be even attempting to reduce the number of frozen accounts. Instead, just make it a clearer process to get out of.

If they stopped doing seemingly arbitrary freezes, this would solve both problems.

</comment><comment><USER23> It's been so long that paypal has had their reputation, I can't _imagine_ using their services based on a statement from _paypal_.

paypal and godaddy -- I mean, come on, why would you if you didn't have to?

<comment><USER24> Because you use eBay, because they're the 1000lb gorilla that everybody knows.

And, because they're the biggest host out there, because their prices are actually really good, because they're the 1000lb gorilla that everybody knows.

</comment></comment><comment><USER25> The article doesn't mention Bitcoin as an alternative :(

<comment><USER26> That's because Bitcoin is an alternative currency and Paypal is a credit card processor. Until all of our mothers are comfortable with and capable of exchanging USD to Bitcoin and then paying with it (as well as paying the BTC exchange's percentage in addition to the purchase price of what they're buying), Bitcoin is not an alternative to traditional USD credit card processors and should not be treated as one.

</comment></comment><comment><USER27> I still remember this: <http://news.ycombinator.com/item?id=4494216>

</comment><comment><USER28> I hope to see a follow up with details on what exactly they've done, in the near future.</comment>


Microsoft disqualified from first offical EU cloud office software procurement - <AUTHOR> http://translate.google.com/translate?sl=sv&tl=en&js=n&prev=_t&hl=sv&ie=UTF-8&eotf=1&u=http%3A%2F%2Fwww.idg.se%2F2.1085%2F1.489504%2Fskrivbordsberoendet-fallde-microsoft Kammarkollegiet is a Swedish authority that amongst other things performs procurement deals for Swedish government authorities and counties.
Microsoft claims they were unfairly disqualified by the conditions of the procurement since they required users to have a local Microsoft Office install. The winners of the official procurement are Google Docs and VMWare Zimbra.
Microsoft also says that they put extra care in this procurement since it is the first of its kind within the EU. <comment><AUTHOR> Microsoft says they were unfairly disqualified because they require each user to have a local install of Microsoft Office.

They also say this is the first official procurement of this type of service in Europe.</comment>


Build your own Netflix: Castro - <AUTHOR> https://umur.io/build-your-own-netflix-castro/

<comment><AUTHOR> OP here, if you have tried and have some feedback, I would be more than happy to hear it</comment>


Show HN: My First iPhone Game, Bodily. - <AUTHOR> http://playbodily.com

<comment><USER2> I'd recommend a video (try vimeo for their aesthetics) on your home page. Looks interesting but a video would probably seal the deal for me.

<comment><AUTHOR> Thanks for the recommendation. A video has been in the works so I'm excited to get one up soon. :)

</comment></comment><comment><USER3> Very cool, are you an experienced game developer or is this your first game?

<comment><AUTHOR> Thank you! First game ever.

</comment></comment><comment><USER4> Did you use Cocos2d or other graphics library?

<comment><AUTHOR> Yes, I found doing so to be incredibly helpful in creating the effects and things I needed. Though there were elements that I had to create with manual functions (such as the random direction many of the "germs" take).</comment></comment>


Want to stop annoying ads? Now is your chance - <AUTHOR> https://www.iab.com/newadportfolio/ <comment><AUTHOR> The IAB (digital ad trade group) is proposing a new standard called LEAN in response to ad blockers. These ads are supposed to be non-invasive. The public comment period has been extended to Dec 22. This is the public's chance to shape the standard before you start seeing these EVERYWHERE.

Send your thoughts to email@example.com

Full guidance is here: [http://www.iab.com/wp- content/uploads/2016/10/IABNewAdPortfo...](http://www.iab.com/wp- content/uploads/2016/10/IABNewAdPortfolio_DRAFTforPublicComment_2016_FINAL.pdf)

A partial list of proposed ads:

1\. Flexible ad sizes - [https://www.iab.com/wp-content/uploads/2016/09/new- ad-portfo...](https://www.iab.com/wp-content/uploads/2016/09/new-ad-portfolio- home-10.png) Replaces fixed pixel banners

2\. Vertical video - [https://youtu.be/ODIqEGJmWjw?t=13m31s](https://youtu.be/ODIqEGJmWjw?t=13m31s) NOT user-initiated

3\. 360 images - [https://youtu.be/OgdGkAxzZaY](https://youtu.be/OgdGkAxzZaY) User-initiated

4\. Outstream video - [https://vimeo.com/193523156](https://vimeo.com/193523156) NOT user-initiated Will autoplay on all wi-fi connections

5\. Interstitials - [https://youtu.be/ODIqEGJmWjw?t=32m13s](https://youtu.be/ODIqEGJmWjw?t=32m13s) NOT user-initiated

6\. Mobile adhesion banners - [https://www.iab.com/wp- content/uploads/2016/09/new-ad-portfo...](https://www.iab.com/wp- content/uploads/2016/09/new-ad-portfolio-lean-examples-20.png) These stick to the bottom of the screen as you scroll

Under consideration but implicitly endorsed

7\. Scrollers - [https://youtu.be/A-jTMJMh4sU](https://youtu.be/A-jTMJMh4sU)</comment>


Rice, black-eyed peas, kool-aide - <AUTHOR> http://video.google.com/videoplay?docid=-3625536419231928674 It's political day all across the nation. <comment><AUTHOR> It's one of the best documentaries I've ever seen.

<comment><USER2> I agree...but not exactly on topic, is it?</comment></comment>


What do you use to sync Docker during local dev? - <AUTHOR> I have a team that works with w/m/lamp stacks and mean stacks. In order to streamline onboarding new devs, I'd like to move to Docker. We have Windows and Mac devs.
The catch I'm having is that you can't edit a file in Docker and see the changes in the docker environment. Synced/mounted folders are sketchy at best. Files stop getting monitored because they're destroyed by an editor like Vim, or something the sync'd folder is completely empty.
Tried: vboxsf -- Doesn't always mount folders Tried: nfs -- Doesn't work in Windows
The best tool seems like rsync, but I haven't put the time into it, because I've lost so much time already just fighting with this one issue. Everything else is working. Docker builds the SQL (or Mongo) servers, provisions them, and even deploys them to the cloud.
Please help me with my local dev woes! <comment><USER2> One thing I'm working towards on a Mac is to have a NFS server VM, and storing the working files in the exported NFS share. This sidesteps the vboxsf rubbishness, and changes the problem from the host needing a server to only needing a client. I _think_ nekodrive should work for this on Windows, but I've not tried it. Mac works fine.

<comment><AUTHOR> That's an interesting way to resolve the issue. NFS works well for Mac, and I'm told it's unsupported on Windows, but setting up NFS in this way might work. Furthermore I might be able to find an NFS image for Docker that I could just fire up on the side... /me ponders</comment></comment>


Why do people waste so much time at work? - <AUTHOR> http://www.bbc.co.uk/news/magazine-32829232 <comment><USER2> "We must do away with the absolutely specious notion that everybody has to earn a living. It is a fact today that one in ten thousand of us can make a technological breakthrough capable of supporting all the rest. The youth of today are absolutely right in recognizing this nonsense of earning a living. We keep inventing jobs because of this false idea that everybody has to be employed at some kind of drudgery because, according to Malthusian-Darwinian theory, he must justify his right to exist. So we have inspectors of inspectors and people making instruments for inspectors to inspect inspectors. __The true business of people should be to go back to school and think about whatever it was they were thinking about before somebody came along and told them they had to earn a living. __" \-- Buckminster Fuller, 1930

<comment><USER3> We tried this idea, in America, at the Jamestown Colony. They initially established it in a "socialist" vein wherein everyone received an equal share of the proceeds (food, etc) regardless of their contributions to the colony. The colony barely survived because people lacked the incentive to work and produce because there was no advantage to them working more than their peers. Why should I work to produce an excess when Billy Bob sits on the dock all day and receives the same share I do. When they lifted the socialist mandate on redistribution, production at the colony skyrocketed because people were rewarded for their effort.

Everyone has to put a roof over their head and food in their belly. If we create a culture that tells people they don't have to work to receive those benefits, it will disicentivize people to actually work (why should they if their excess production goes to subsidizing non-producers who stare at the sky all day?) and engage in production activities. Supporting a society necessitates producers create more than what they need, but if you create a system that takes what it deems the excess from the producers without compensation or reward and doles it out, the producers will stop producing and we'll back at Jamestown all over again.

<comment><USER4> There was nothing "socialist" about Jamestown. Many of the initial settlers were aristocrats who had no experience of work, and no interest in it.

Unsurprisingly this didn't end well.

>If we create a culture that tells people they don't have to work to receive those benefits, it will disicentivize people to actually work.

We already have a culture like this. Those who believe they own an entirely imaginary thing called "money" believe they're entitled to live off the efforts who don't.

It would take an outbreak of unreasonable optimism to claim this is the most efficient and productive of all possible systems - especially considering it's notorious for its many completely predictable failure modes.

<comment><USER5> _Those who believe they own an entirely imaginary thing called "money"_

The fact that someone can write this is laughable to anyone that was ever poor in their life.

Money is not at all imaginary. It's quite real. The lack of money can ruin your day, your year, your life.

As for what money is - it is a productivity storage mechanism. Once you've been productive it allows you to store that productivity in a fungible form. It allows you to exchange that stored productivity for the productivity of others, give it away to someone else or basically do anything you want with it.

<comment><USER6> The fact that anyone was ever poor should be an affront to anyone who believes that money is real. People of your ilk are fond of resorting to the old canard "everyone needs a roof over their head and food in their belly". Well, there quite simply is an astounding surplus of such. Those who really believe that the lottery system we currently use of assigning who gets what is truly effective and just will have to answer for that someday.

Money is only powerful because a quorum of people have mutually agreed to believe that it is. One of the things I enjoy pointing out is that the stock market is a wonderful example of the power of belief. When enough people believe it's going to crash, guess what happens?

<comment><USER7> What I feel many people miss is that goods and money are not synonyms. If there was a huge influx of money into the world, that helps exactly nobody because the amount of food, shelter and other goods has not increased.

I find that people "get" this a lot easier when you start talking about coupons and IOU instead of gold and dollars. Nobody believes that the guy who is moving coupons back and forth between various piles with specific timing has truly earned the load of goods he gains. Instead, they rightly feel like he is cheating the system and taking without giving back.

But in the real world, tons of people do tricks with money and get filthy rich from it, and that's just them "working smart". Meanwhile, somebody had to grow that potato, the actual tangible good, that he ate for dinner. What did he give back in return?

<comment><USER6> Sure, and that reminds me of another great example for money's imaginary quality: The total amount of money in existence is many magnitudes more than it would theoretically take to end global poverty. However, no one dares attempt this, because it would knock the struts out that prop up the whole system (namely, debt).

<comment><USER8> > The total amount of money in existence is many magnitudes more than it would > theoretically take to end global poverty.

No quantity of money can end poverty, and no reasonable theory suggests that any amount of money can.

Systems of distributing goods and services (whether or not money is used as a proxy in those systems) might, but the quantity of money existing is pretty much irrelevant to that.

> However, no one dares attempt this, because it would knock the struts out > that prop up the whole system (namely, debt).

Money _is_ debt. Even commodity money -- as long as it is being traded not to be used for its intrinsic properties but for future exchange -- is essentially being used to separate the two sides of a barter transaction so that you don't need to exchange things of direct use such that the money then becomes, in effect, a marker of debt from the whole of the money-using society to the money holder.

So, yes, "debt" is the foundation on which the whole system of money is built because debt is what money is (modern fiat currency represents the abandonment of even the pretense that there is something else to it, as that pretense has always been costly to the function of money.) But if you think you can rearrange money to achieve some goal _without_ maintaining its nature as debt, you don't understand money at all.

<comment><USER6> > No quantity of money can end poverty

What definition of poverty are you using? Certainly studies have been done: [https://www.oxfam.org/en/pressroom/pressreleases/2013-01-19/...](https://www.oxfam.org/en/pressroom/pressreleases/2013-01-19/annual- income-richest-100-people-enough-end-global-poverty-four)

> the quantity of money existing is pretty much irrelevant to that.

I mean, that's what I'm saying, but as it is now, if I had a billion dollars, I could build a few wells in Africa, yanno?

> Money is debt...

Clearly, but in addition to that, my point is that the system of money needs people to be in debt. There's no "neutral state" as it were, and indeed, many of the efforts of the IMF and World Bank are calculated to get poor countries further in debt.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Because if they got their job done and left they would be fired. If they got their job done, they would be given more work. So one takes the maximal amount of time to do a task given the requirement that they be in the office for 8+ hrs a day.

<comment><USER10> If they have 8 hours of work time and finished their tasks in 6, does that mean they have exhausted their usefulness to the business? Why not spend these 2 hours doing some small miscellaneous tasks?

<comment> FLUX-YOU >Why not spend these 2 hours doing some small miscellaneous tasks?

Because that's scope creep and it can create the expectation that it's part of my job, so then I'll be responsible for it. Down the line, if one of those misc tasks becomes the ire of someone else and my name is attached to it (comment, commit, etc.), they'll contact me further down the line, perhaps when I'm dealing with something of my own. Then, at least, I have to explain that I don't maintain that and in the worst case (which has happened), I have to fight to not be responsible for it right then.

There's a balance in having your name associated with 'things' in a business. Some people might be good at being a know-it-all, being well-known, and handling everything (why aren't they running their own company?), but you'll increase your chances of interruption the more wide-spread your name is.

<comment><USER11> Yep exactly. Try adding unit tests to legacy code when your coworkers consistently ignore it. They'll be praised as fast workers who kinda sorta get the job done. All you'll get is called out for being slow and be tasked with fixing someone else's mess and your code won't be a maintenance burden.

It feels like in software dev we can just make messes and move on without accepting responsibility. Increasing scope on yourself with those small misc. tasks also means accepting more responsibility than most software devs accept which makes you a target when things don't go smoothly either through your fault or someone else's.

The biggest catch is that those 2 hours that you have butt in seat means you can't work on your own skills/side project for fear of the employer owning the code. The only thing you can do is take online courses at Coursera or Udemy as they're general enough skills.

</comment></comment></comment></comment><comment><USER12> I'm reading this at the moment:

[http://www.reinventingorganizations.com/](http://www.reinventingorganizations.com/)

Some extracts from the intro:

"And it's not only at the bottom of the pyramid. There is a dirty secret I have discovered in the fifteen years I have spent consulting and coaching organizational leaders: life at the top of the pyramids isn't much more fulfilling. Behind the façade and the bravado, the lives of powerful corporate leaders are ones of quiet suffering too. Their frantic activity is often a poor cover up for a deep inner sense of emptiness. The power games, the politics, and the infighting end up taking their toll on everybody. At both the top and bottom, organizations are more often than not playfields for unfulfilling pursuits of our egos, inhospitable to the deeper yearnings of our souls.

This book isn't a rant about large corporations gone mad with greed. People who work in government agencies or nonprofits are rarely more exuberant about their workplaces. Even professions of calling aren't immune to organizational disillusionment. Teachers, doctors, and nurses are leaving their field of vocation in droves. Our schools, unfortunately, are for the most part soulless machines where students and teachers simply go through the motions. We have turned hospitals into cold, bureaucratic institutions that dispossess doctors and nurses of their capacity to care from the heart. "

"The way we try to deal with organizations' current problems often seems to make things worse, not better. Most organizations have gone through many rounds of change programs, mergers, centralizations and decentralizations, new IT systems, new mission statements, new scorecards, or new incentive systems. It feels like we have stretched the current way we run organizations to its limits, and these traditional recipes often seem part of the problem, not the solution.

We yearn for more, for radically better ways to be in organizations. But is that genuinely possible, or mere wishful thinking? If it turns out that it is possible to create organizations that draw out more of our human potential, then what do such organizations look like? How do we bring them to life? These are the questions at the heart of this book. "

<comment><USER13> Also reading this. Great book.

</comment></comment><comment><USER14> Before we get into a discussion about basic income and drones making us obsolete, can we talk about cutting hours? First, lets get back to the standard 40 hour work week. That'd be a big step. And after that, can some of us work less? Half of my day is spent browsing the internet out of boredom. I'd get more done if the day was shorter. Better yet, let me telecommute and set my own hours. You'll get the same results out of me, if not better, and I'll be a happier fellow.

<comment><USER15> I totally relate to you. I'd myself personally prefer going half-time (20 hrs/week), with the option of working extra hours. (Perhaps a 5-hours-a-day 4-day work week.)

</comment></comment><comment><USER16> In my case it's the lack of documentation about a huge system (ecosystem, I'd rather call it), in contrast to an overengineered methodology and process, which involves mandatory code reviews by people unfamiliar with the code and 6 test phases before production.

If I crank 10 lines of code a week I consider myself lucky, and it won't take less than 3 weeks for them to hit production.

The combination of that with long builds and releases (30min minimum) makes me always have something to do, but I'm always waiting for something to be able to move on (build to be finished, answers from experts, validation by QA...). That's where HN and r/programming kick in.

<comment><USER17> I sincerely hope this (10 lines of code a week) is hyperbole. I would be fine with 3 weeks to hit production - not everybody works on a SaaS, I've had six months release cycles - but... not writing code?

<comment><USER18> I've probably not even gotten 10 lines a week at some jobs. One gig was mostly all ad hoc reporting stuff, with a lot of cut and paste of previous impls. Another place I and two others spent a year on a project that should've taken 2 months, I didn't write any new code at all for at least 6 months of that project. Specifically there was a lot of back forth, requirements changes from the business owners, on the part I wasn't involved with, before the project went live.

This was typical for the first 10 years of my career until I took a lead position. Now I work all the time, and I focus on organizing and coaching up my team so I don't have to do as much.

</comment></comment></comment><comment><USER19> I think this involves setting some clear boundaries and expectations. I learned some things while I was consulting that I've carried into everything since:

\- After a certain time each evening (7pm for me), stop sending email. You can still write and respond to it but schedule it to go out the next morning. If people see you respond at 2am, they'll begin to expect it.

\- Do the same for weekends. Schedule email for Monday morning. If people see you respond on Saturdays, they'll begin to expect it.

\- Only check email every N hours. I've found N=3 or 4 is best. This is the hardest for me. If you respond to every email in minutes, they'll begin to expect it.

\- If you're not explicitly on the To line, filter it from your inbox. I have an "other stuff" folder where email goes if I'm not explicitly on the To line. I check this folder 1-2 times/day at most. If something is important to me, address it to me.

\- Have a fixed todo list each day. If someone brings you a task, put it at the end of today so it often ends up tomorrow and communicate that. (Obviously, if something is _really_ important, you can shift the order but that should be an exception, not the practice.) If you drop everything every time someone asks, they'll begin to expect it.

\- Leave the office at a predictable time each day. I try to leave by 6pm. If you occasionally stay late, they'll begin to expect it.

\- Don't answer your phone the first time someone calls. I always wait until their second call or if they email/text/dm too. If you're always-accessible, they'll begin to expect it.

\- Don't take your phone into the bedroom at night. I leave mine charging on my desk at the other side of the house. If you answer your phone in the middle of the night, they'll begin to expect it.

<comment><USER19> I should note two extra benefits from not always being available:

\- many problems often resolve themselves

\- those people who would rather ask someone instead of google, tend to learn to google.

</comment></comment><comment><USER20> Because we are playing the game. Some call it presenteeism, other call it face time, some even view it as the boss owning your ass during the work hours. But basically, we don't really give a fuck for the organisation, for the team, for the project, for the job. We just do enough to keep the gig until something better rolls along. We know you would have no hesitation to cut jobs and other such when it suits, so don't expect any more from us.

</comment><comment><USER21> > In this respect, entire occupations might be considered phoney - from life > coaches to "atmosphere co-ordinators" (people hired to create a party vibe > in bars) to "chief learning officers" in the corporate world.

People hired to create atmosphere in bars might be "phoney" in an object-level sense, but as far as their job goes presumably they do provide an actual service to someone, by causing more people to visit the bar.

<comment><USER22> It's still a Bullshit Job. [http://strikemag.org/bullshit- jobs/](http://strikemag.org/bullshit-jobs/)

The answer to the BBC news story's question is: "because our jobs increasingly have more and more bullshit."

<comment><USER23> People creating a vibe in pubs doesn't feel like a bullshit job. They're providing a service to other pub goers, making it a more pleasant place.

You can't ignore pleasure and satisfaction of other people when considering a job is useful or not. In the end, those are the goals of anything we do; that the job does it directly rather than indirectly (by say improving industry, which makes life easier, which means people have more free time, which provides happiness/satisfaction) doesn't make it 'bullshit'

<comment><USER22> I would disagree. Emotional labour is the essence of many a completely bullshit job.

<comment><USER24> The pub should A/B test having the person there, and not there, and look at the bar sales. That would determine if it is bullshit or not.

If the person creates a vibe that gets more people there, e.g. patrons texting friends to stop in, or increased bar sales by people staying longer then it might be worth it.

Of course if the bar hired bartenders that created an atmosphere of fun whilst doing their jobs then that would be even more profitable.

</comment></comment></comment></comment></comment><comment><USER25> I don't think it was ever different. The idea that there should be enough time to sleep and have hobbies, that's the new thing. Just because our parents already experienced these privileges doesn't mean it's an old topic.

And if something like this happens so regularly, so naturally, I think instead of logically arguing about it we should worry more about how to handle that. I'm thinking about that other article were sales people were working together to make it looks like they all would work 80 hour weeks.

Last but not least let's not forget that our bosses also actually don't care abut our work hours. Caring would mean that they would need to look at hour work schedules and time tables, etc, instead of going to the golf club. For them it's more important that they can make a good impression on their bosses and customers as well. As long as we deliver that impression they don't mind that we all act like we are working 80 hour weeks, including them.

</comment><comment><USER26> We all know the answer is HN.

<comment><USER27> HN time is not wasted.

<comment><USER28> [citation needed]

<comment><USER29> [https://news.ycombinator.com/item?id=9603608](https://news.ycombinator.com/item?id=9603608)

</comment></comment></comment></comment><comment><USER30> I'm surprised no one mentioned Holacracy yet.

As others have mentioned, doing "just enough" work is a by-product of a inefficiencies of the hierarchal approach of managing via command and control. Holacracy instead is network centric.

I don't know if I completely buy into the effectiveness of Holacracy but I can see how it it is better motivating to Producers. For example, I tend to write better code knowing that it will be peer-reviewed by another dev I respect.

</comment><comment><USER31> Because working hours are inhuman.

</comment><comment><USER32> because I pay you for 40h of productivity per week, not a fixed amount of output? for the latter, consulting/freelance exists.

if you get paid for 40h per week, the expectation is to devote those hours to the benefit of the employer. do your tasks, if you have time to spare, think of other benefits - improvements, better ideas, learn, etc.

people that finish a task and then wait to be given another are the bane of the workplace. you never hire them at startups, but at some size they creep in and kill, kill, kill any company. walk into HP, Oracle, IBM today and you'll see them, in droves. that is why you can lay off 30% workforce at that size with no sizeable impact on your customers.

<comment><USER33> Are you paying hourly or salary? If salary, you are paying for what should be able to be done in 40 hours a week, but if it takes 45, you expect it to still be done, no? So if one can get it done is 35, why do you expect 5 more hours to given free?

<comment><USER32> No, I pay for 40h of your attention. for things that don't fit into 40h there is either (paid) overtime or hiring, depending on frequency.

<comment><USER33> So you don't hire exempt employees?

</comment></comment></comment></comment><comment><USER34> Stress makes the brain lose focus.</comment>


A list of themes and starters for JAMstack sites - <AUTHOR> https://jamstackthemes.dev/ <comment><USER2> Wow, nice collection of themes! I could have really used something like that a few months ago. I developed a Gatsby site and literally spent an hour searching for a good-looking theme.

</comment><comment><USER3> I'm a data engineer but my blog is a JAMstack site!

seisvelas.github.io

To host the posts I just use embedded Github Gists and call them with the Gist API with React. I made this project at work after one of the web devs did a seminar thing on React Hooks and I wanted to try it out! It's weird how web dev seems to move so fast, yet the general approach seems very similar to the jQuery/PHP days (the last time I did any serious web development).

Edit: I like this more than static blog generators because I don't have to rebuild / publish when I want to post. I just make a new Gist who's filename starts with 'blog_' and my site will filter for all the blog posts when the page is loaded!

<comment><USER4> Great idea using Gists to power your blog!

Regarding "rebuild / publish when posting" Some static site generators can generate sites in a matter of milliseconds. The advantage of using static sites is having fully SEOed site. Though it might require of having an additional step of manually triggering the build, or if possible, wiring the build process to some kind of webhook when the content changes, or in your case, a Gist is added.

</comment></comment><comment><USER5> I thought Jamstack was just sort of a collection rules about the state of the site was tech wise.

Why would there be a JAMstack specific ... theme?

<comment><USER6> Currently, JAMstack well supported by infrastructure. I suppose, why not to have themes to build sites in minutes? Pick theme -> deploy.

</comment></comment><comment><USER7> Has there ever been a better time to be a web developer!?

Good stuff Ohad and team!

</comment><comment><USER8> This is so useful</comment>