skysight-inc/HackerNews huggingface dataset:
If you can separate something out into it's own completely independent and reusable module, you should always do so.
Also if something can scale by adding concurrency, that is often a good strategy.
For example in conferences where every participant is supposed to talk, you can divide them into groups, so many people can talk at the same time but in small groups.
True.

Founding a company is the only way to shape your own success.
Do you see in advance how many times you will have to do ]b or [b? For me this is the advantage of tabs over buffers, and it's faster than checking the buffer every time it changes.
A microservice, imo, should just be a simple black box that takes in some input and returns some output (sometimes asynchronously). No side-effects necessary. No fiddling with database flags or global state, and definitely no hitting other microservices. See @CryoLogic's post for a good example. This means that you simply can't build some things using microservices -- like logging in a user -- and you'd be right.
It will depend in part on what they are doing. I had limited internet when I was homeless and had to cope with doing stuff on a tablet in the evening with battery power and no internet.

Find games that can be played offline.

Use a URL to PDF converter for things you want to read.

Favor lightweight websites and lightweight apps.

Get a video downloader and download videos you like watching repeatedly, like music videos.

Clear your cache regularly and delete stuff you aren't really using.

Try several different browsers to compare performance. After finding one that works well, uninstall all others that can be uninstalled. Some mobile browsers have an optimization option that will help.
It's nonsense when talking about bytes. As others have pointed out, most switches/routers work with chunks of 16-64 bytes at a time, not singles.
I think it'd be an example of Campbell's Law (or the closely related Goodhart's Law).
By most definitions of microservices I've heard there's a 1:many relationship between microservices:datastores. Multiple microservices can't talk to the same database. For example:

> While monolithic applications prefer a single logical database for persistant data, enterprises often prefer a single database across a range of applications... Microservices prefer letting each service manage its own database, either different instances of the same database technology, or entirely different database systems https://martinfowler.com/articles/microservices.html

Not to say that pattern can't be successfully implemented, just that it wouldn't be considered microservices. It sounds like you're describing a three-tier architecture: https://en.wikipedia.org/wiki/Multitier_architecture#Three-t...
What would be an example of a situation where the backend dev needs to change a field in the database?
At what point does California stop and realize that they are going to eventually tax themselves out of business?
Let me try another way. P = profits, R = revenue, S = salary, E = expenses:

P = R - S - E

Every dollar you get in salary is a 1:1 drop in profits. Any bonus B you get,

P = R - (S + B) - E

is the same. You might expect from this, then, that if you're offered a S+B package, the S would be lower than what you'd get with a pure S offer, by the expected amount of B. And you'd be right. I've been on both sides of the negotiating table, and this is how it works.
I think they do. I have submitted a link before and been redirected to the existing comments page.
Once when starting a new gig I inherited a "microservices" architecture.

They were having performance problems and "needed" to migrate to microservices. They developed 12 seperate applications, all in the same repo, deployed independently it's own JVM. Of course if you were using microservices, you needed docker as well, so they had also developed a giant docker container containing all 12 microservices which they deployed to a single host (all managed by supervisord). Of course since they had 12 different JVM applications, the services needed a host with at least 9GiB of RAM so they used a larger instance. Everything was provisioned manually by the way because there was no service discovery or container orchestration - just a docker container running on a host (an upgrade from running the production processes in a tmux instance). What they really had was a giant monolithic application with a complicated deployment process and an insane JVM overhead.

Moving to the larger instance likely solved the performance issues. In place they now had multiple over provisioned instances (for "HA"), and combined with other questionable decisions, were paying ~100k/year for a web backend that did no more than ~50 requests/minute at peak. But hey at least they were doing real devops like Netflix.

For me, I've become a bit more aware of cargo cult development. I can't say I'm completely immune to cargo cult driven development either (I once rewrote an entire Angular application in React because "Angular is dead") so it really opened my eyes how I could also implement "solutions" without truly understanding why they are useful.
This behavior happens already, but only if the link has gotten sufficient attention.
yeah, I was kinda focusing on stuff available on consoles more than three hundred people ever saw. :)
They could capture the canonical URL from the meta tags in the page. I don't think they do currently.
It's not about generating the exception. It's about not operating on privileged data. (And not loading it to registers seems a good way to not operate on them, btw)...

Generating the exception can still obviously happen at retire. It's not even a problem to run an extra bunch of code with constant placeholder garbage data (if that would be too costly to interrupt it sooner), given you know all is gonna be cancelled by the eventual exception anyway. But you just don't fucking load the privileged data to begin with!!! Timing side channel attacks have been known for maybe a decade for heaven's sake. Even if Meltdown would not have been as simple as it is, as soon as you speculate on privileged data you are completely dead; because there will be tons of obvious side channels to retrieve said data. (measuring occupation of execution units through HT comes to mind, actually before meltdown was disclosed I thought this was the trick to leak the data that should not have been loaded, turns out it was even simpler...)

Maybe the field needs better "textbooks", or to return to the classics about speculative execution. I've yet to see anybody blaming Intel for Spectre. Some other designers might have made the same mistake as Intel for Meltdown, but that does not make it less a mistake.

Maybe AMD only had it correctly by some kind of strange accident, and it will probably be very hard to know. That would still be a silly mistake for Intel, even then.
one page view

http://www.nytimes.com/1989/07/02/magazine/the-joys-of-victi...
Hardware is first pillar content is the second. Why would I buy the first if the second doesn't exist?
Typo: the name is dxvk, not dVXk.
A brief YAML reference
This is just a relative jump instruction and on intel can be just 2 bytes, although an ignop might fit into one.

It wouldn't solve the icache problem though. Also, writing to data inline with code would be super problematic performance-wise with modifying icache lines that currently are being executed from.
What even is error handling? (2018)
It's not specifically the DOM modification but the way those frameworks are designed. With React you have hundreds of dependencies, which have hundreds of dependencies. You lost me right there.
>I don't think that's true at all

Funny thing about the truth is that it doesn't matter if you think it's true or not. It's still true. I make a living traveling for work, and I make a hobby of finding out small downtown areas and visiting them, and there's never a shortage in basically any thriving region of people out and about doing things they want to be doing.

You can point to some dying towns and say "look, these guys closed the business so that disproves your point" but forever in the history of forever, towns have been growing and towns have been shrinking. As one place wins, another necessarily loses.

Visit the Lake Michigan beach in Saugatuck MI, walk the riverwalk in Little Rock AR, head down Broad Street in Lake Geneva WI, grab a beer at Reclamation Brewing Company in Butler PA and tell me people don't socialize anymore. Grab some wings at Chase's in Norcross GA and tell me you'd rather talk about the weather with a stranger at Walmart than eat great food and have a real conversation with Chase's mom on the patio in the cool Georgia night air.

Small talk at Whole Foods isn't socializing. You want people to talk to? Go to where you want to be, and there will be people who want to be there too, and guess what, you already have a conversation starter.
> like forgetting to check error returns

One of the most common bugs in C (in my experience) is forgetting to check the error return on a malloc call. Kind of the worst of both worlds.
"A change in perspective is worth 80 IQ points." - Alan Kay

Thank you for helping stay on track.
It is not a real check. It is for putting on your wall.
ECS ChatOps with CodePipeline and Slack
It's the opposite. I changed the title to take out the celebrity names because in our experience those tend to trigger poorer discussion.
It's not like you'll be the only person in the Amazon store.
55 seconds in it does show them grabbing misplaced items, if that's what you mean.
Looking for co-founders
Hi all,

I'm looking for a co-founder for my startup as my current co-founder is leaving the company to invest full-time in crypto. There has no been any bad feelings or anything, he is just not interested in the industry.

Matter is, we're very close to some deadlines and there are 3 clients waiting to try it out (which is good, as long as we deliver). Also, there is some more good stuff.

So, I'm looking for someone who has built real, bullet-proof react + node.js apps. The better if you've build a chat used in production before. But hey, that's not etched in stone.

Anyone who wants to give it a try will need to work with me for a couple weeks before accepting and transferring the shares and all that stuff.

(company is based in London)

If anyone is interested ----> please, reply below:
Debugging Electron Memory Usage
Interesting PixelBook pen hack
Maybe if they paid competitively they would be able to attract new grads. Many of my Berkeley and Stanford EE acquaintances are joining Apple, Facebook, and Google as hardware engineers and getting 6 figure initial RSU grants and $140k starting salaries (this is at the PhD level). Even Intel, which has among the best pay in the traditional semi industry, pays about 20-30 percent less total comp, and so they are only attracting either the people still intensely interested in their specialty (and willing to forego pay) or those who couldn't pass an interview at the aforementioned other companies
I would encourage you to forget about hardware and concentrate on the software and applications.

Based on my experiences (I work for an ISP but we have a "sister" company that's an MSP that provides IT services to, among others, several K-12 schools in such rural areas), most of these schools either 1) already have available hardware (iPads, Chromebooks) due to existing 1:1 programs or 2) have decided to not (yet) pursue that (usually because of financial reasons).

In the former case, they already have hardware and don't want to buy even more. In the latter, they simply don't have the money for it (it'll be an even harder sell if it's not "general purpose" and can only be used with your stuff). Even if you manage to get it under $50 per student, that's still a lot of money that they could likely spend elsewhere.

Develop your applications and concentrate on targeting the most popular platforms (iOS and Android) and forget about trying to sell them hardware they can't (easily) reuse. Definitely forget about cellular connectivity and stick to Wi-Fi instead.
Hello, Thank you kazishariar !
Right now, we are not using a special framework for managing system, Edx maybe our primary choice if we think about a all-in-one system. But instead, we decide to build apps by categories instead of building a generic one. We are focusing on the way we create content by subject.

We started developing a story editor with basic images, texts, and sounds (so we can add effects in the story). We also developed a small version of a simple sheet music editor with a virtual piano and sounds.
For geographic, historic and animals anatomy illustrations, we use a map-like editor, so the teacher can draw shapes, add voice, timelines ...

For the internet access, there are many places that already covered by 3G service, What's good for us, is that the area size of the country is small, so, network providers can extends theirs services without huge investments.

Tell me if i replied your question or missed something !
Oh yeah I live in detroit my roomate told me about this. Pretty interesting news around here.
Recognising the fallacy of a single root cause
That's why high assurance systems (like L4/seL4) minimize privileged code to a tiny fraction of what you find in a regular system, which absolutely makes sense and provably improves security.

Apart from the obvious advantages, minimal privileged code also means that it becomes far more feasible to formally verify the privileged code, like it has been done for seL4, which in turn is an important cornerstone to ensure that isolation (or more generally, specification invariants) does not break in any reachable system state.
Would you please stop using HN for ideological battle? This kind of argument is always predictable: people trading the same grievances and counter-grievances over and over.

The culture wars and all that crap are beyond tedious, it's all off topic here, and the vast majority of HN users have zero interest in it. People shouldn't have to wade through sludge every time anything distantly related shows up. If you don't find this article interesting, that's fine, but please don't trash the thread for those who do.

Alan Kay famously said that a new point of view is worth 80 IQ points. An ideology is worth -80.
That's how we used to build systems back in the 3-tier architecture (DB, app server, UI) days. Usually backend servers would be hooked up to a workflow engine or message bus like Celery, JMQ, or plain old crontab to do batch tasks.

It's not a bad system - it worked for a technology generation, from around 1997-2012 - but it's somewhat limited in the problem domains it can solve effectively. Anything real-time or with high change volume becomes problematic, because each service needs to poll the DB for work to do. The DB can quickly become a scaling bottleneck. It's not as well-suited to thick clients, because you need an app server in front of the DB anyway to check & validate requests so the entire world doesn't get access to all your data.

On the plus side, state coherency becomes much easier, because all state is in the DB and you can use transactions to update it atomically. I also disagree with the posters who say that updates & versioning are a nightmare: they are, but updates are a nightmare in any distributed system, and sticking an app server in front of the DB just makes it easier to know when you've made a breaking change, it doesn't make the change itself easier. I've worked on large (= Google) protobuf-based SOAs before, and changing anything that touches backend protocols or storage is difficult regardless of which architecture you use.

I'm a big fan of the "solve the problem first, scale the architecture later" approach. For your first version, just store everything in hashtables/lists in RAM, in a single process, and serve out RPCs to client code (or run a webserver) as necessary. At this point, you don't have a useful product anyway, so it doesn't matter if it goes down and loses all data. Once you have something that's useful, work on moving state out to external systems: at this point, you have a pretty good idea what the schema should be, so you can save on a lot of migrations. Split into separate services when the computational resources exceed the ability of a single process to service them; before then, just split it up into libraries.
There are multiple steps in the determination of profit ("earnings"), which I think is the cause of the confusion.

Folk tend to fixate on gross profit, because that's the pointy end of their direct market relationships. I buy a banana and it has an x% markup over the price paid to the distributor. That percentage may be quite high and if I'm aware of it I may think someone is taking the piss.

But of course gross profit is just the beginning: you need to deduct SG&A (which is where the senior managers live), R&D (the engineers) and other bits and bobs before arriving at EBIT.
I've noticed several grocery stores in the largest cities I've been in (Shanghai and Tokyo) lack carts both due to space constraints and because people visit on their way home either to or from the train station. Shopping carts are mostly necessary/convenient in suburban environments where you have to drive to bigbox stores because you live too far away.

Judging by the area of the city that Amazon Go is in and the ubiquitous housing nearby. I suspect this is the model they're going for.
This smells like a straw man argument. Most of us don't have pie in the sky ideals about perfect codebases. we have practical, hard won expectations of a work-person like codebase and we want to build to that standard - not some higher perfection ideal. And being prevented from having good engineering by "get it out the door no matter what" is frustrating because 99.9% of the time that leads to crap service, overruns, and more crap work on top.

the exceptions like say "move fast and break things" are ... exceptions not the rule. your company is not a facebook like special snowflake and using the snowflake argument to drive poor engineering decisions just makes you look silly.

one essay i remember from ages back on Joel On Software was him describing working at a Jewish / Israeli bakery. the bread oven was rusty and broken on the outside and looked like crap. but inside it was spotless stainless steel, because the bakers knew that the inside was what counted, and any money spent polishing up the outside of the oven was just waste.

that is an exeellent way to see the software / value argument - you have to know where the value comes from, and make that part fucking perfect. the rest can just be hung together with string.

Any disagreements on which part needs to be perfect is really a misalignment if understanding the business
> But how do they benefit society?

Tsunami hits Japan and some Japanese computer memory factories are shut down. As soon as this news hits America, the prices of computer memory chips is expected to go up. But there is a delay in how quickly different people hear the news. Some American memory chip sellers might still be selling at the old (lower) price, while some of their better-informed customers seize the opportunity to buy before the prices go up. In this instance, the sooner the news reach America, the American resellers know to increase their prices, and they get the benefit from the increased prices. (And some buyers end up paying more.)

Later, the Japanese have rebuilt and the factories are about to start producing again. Now memory chip prices are expected to go back down. The sooner the new information spreads around, the more people will benefit from buying at the cheaper prices. (And some resellers will disbenefit by having to decrease their prices sooner.)

The well-informed market makers keep the prices as current as possible.

Buyers benefit from new, cheaper prices, but sellers disbenefit. Or the other way round. But we believe that efficient markets are beneficial to society, so the benefit for whoever gains by buying/selling at the most recent price information is larger than whoever lost because they couldn't sell/buy at the old price.
Get to work full-time on an off-grid self sustaining home, and after that start preparing the area to form a community. I am not interested in "sub-dividing lots" to maximize "profit". I want the very foundation of this future neighborhood to be the people and their shared possessions.
Linode. Its in enough places it can be local to you, it has the beginnings of a machine deployment method which can go into kubernetes if you want, it does true IPv6.

I use Linode for work, and a local provider (binary lane) with a /56 for personal at $10 a month or less each.
yes! If you break something out into smaller parts, but they're still entangled, you have actually added complexity instead of reducing it.
I mean I know you think that's how it works, but it doesn't work like that :)
The expected value of the long-term future [pdf]
i don't follow how being born of and dependent on husbandry redeems the suffering of these lives
I would add that job market is only a market when employers are bidding on candidates and people are looking for jobs. The rest of the time it is not a market anymore, as bids are not open and not visible to anyone. So during this time employees slowly undervalue themselves by not participating in a market and employers benefit by not paying the market value and trying to keep employees as long as possible in this situation, essentially always underpaying even that.

EDIT: This was all about short term and mid term behavior. I would like to mention that long term employers and investors can influence job market and increase competition among workers, pushing wages even further down.
That's not a pure microservices approach, since you are sharing state (the database). It means that any development which changes or is impacted by a change in the DB has to be coordinated between teams.

The microservice approach is to have each service have its own database (MySQL) or schema (PostgreSQL).

Another solution is the use of a modular architecture, where separate modules are each responsible for their database tables' schema. Tables are not shared across modules; accessing data from a table requires calling its module's API.

Each module can be developed independently, and combined into one large service or several smaller services. It's helpful to be able to separate modules into their own service for load balancing and optimization, while having all modules in the same service eases administration of the system.

From previous experience, you start by lumping all modules together, then use monitoring software (i.e. ELK stack, collectd/Grafana) you decide where to split into services. Because the reality is you'll not really know where to split until you are running in production.

This is the approach of Django for example and works quite well for large projects.
Data Science in Production: Packaging, Versioning and Continuous Integration
What is copyright breach in one country, it is not necessarily in the other one. One cannot just impose laws to other countries, that is why countries are sovereign.

To impose copyright restrictions in other countries there must be either international agreement or the law in that other country that permits such limits.
The idea that you should consider "what to do if your company grows to be a competitor to Google" in your technology decisions is quite frankly some of the worst bikeshedding I've ever seen. That question shouldn't even enter in to the process at the start.

If that happens, and it probably won't, but if it does you will have a team capable of dealing with the issue by then.
Ahhh: http://www.howmoneywalks.com/irs-tax-migration/
Were metastatic melanoma and NSCLC considered "easy" before immunotherapy? My understanding is that they were near certain death sentences.

I think that the progress so far certainly looks revolutionary compared with the previous few decades. I also agree though that a lot of excitement is related to perceived future benefits.
It could be, but that would be an inaccurate and tendentious. I have the impression you didn't even read it all the way through.