[0] https://gist.github.com/dhh/782fb925b57450da28c1e15656779556
15,526 karma · joined July 20, 2008
[0] https://gist.github.com/dhh/782fb925b57450da28c1e15656779556
This is not to detract from the contributions that Elon has made, but to indicate that there are potential Elons all around you. How many engineers would've built something similar if they had resources? Consider that even John Carmack, despite millions in personal fortune, had to abort Armadillo Aerospace because it was too expensive. If he had a PayPal-size exit, we may've had a SpaceX many years earlier!
It's no good for consumers, but I don't think many investors would be happy to hear that a company is just leaving those data and opportunities on the table.
Look up the "RAM Copy Doctrine". Basically, it means that every time data is copied within the computer's memory, it's a potential infringement. The HTML source of the page you've downloaded undoubtedly qualifies for copyright protection. Your argument would be an implied license to modify the page to make it suitable for display, but standard ToS will typically forbid any type of modification, removing any ambiguity into whether third-party extensions that modify the page may have an implied license. Your license would typically be limited to displaying the page as transmitted, and allowing an extension to read and modify the page would be an infringement.
I'm not a lawyer but I had a neat little SaaS business that was killed by a C&D along these same lines. Multiple attorneys reviewed and this is basically the summary. When I suggested that we do a peer-to-peer data transmission thing to avoid handling or transmitting any copyrighted content, I was warned that doing so could easily be interpreted as conspiracy and that it'd be best not to go down that route. Maybe someone else's attorney would say something different, but that's what mine told me.
As soon as Facebook realizes you're a risk, you'll get a C&D ordering you to stop accessing their servers. These typically have the force of law under the CFAA.
You won't access their servers, but just read the page that the user already downloaded? You'll still get nailed under the Copyright Act.
"User agents" in the sense used by the OP are as old as the internet itself. There's an active, serious, and quiet effort to abuse outdated legislation to ensure that they never become a problem.
I can't recommend fish-shell highly enough for anyone spending significant time in the CLI. It can't completely replace bash et al, but it's not really meant to. Just install it and give it a try and you'll get addicted pretty quickly.
Yeah, I get that there aren't a lot of options besides Bitcoin for unbanked transactions, but there are a lot of potential ramifications around the radical publicity inherent in blockchain-based currency.
If whoever held the coins 3 transactions ago ends up getting in big-time hot water, should I expect the feds to try to confiscate them? I would at least be under additional scrutiny in order to determine what association I had with the illegal enterprise, being so close in the chain. Bitcoin tumblers and mixers only do so much to prevent this, especially as people have started discriminating against "tumbled" btc.
I think this can get tricky. I've worked in several office suites where having a business listed on the directory at the entrance was an additional fee that many tenants opted not to pay (not just struggling startups; I've known this category to include large publicly-traded companies who'd existed for decades). Someone could see that a listed business is not on the directory, mark "no longer exists", even posting "photographic proof" of a directory without the business's name -- and they could still be wrong.
The only way to know for sure would be to a) verify the landlord's records; or b) regularly knock and confirm that employees of said company are routinely occupying the space.
> If your answer is "the entire world is stupid," then I'd argue you don't understand how the field of design is supposed to work.
And I think it really sums the argument up. Good design and engineering is about building something that performs its function efficiently, reliably, and unobtrusively. If something is widely misunderstood or misused, it's a design flaw.
"Blame the [law-abiding] citizens" is just as much of a cop-out as "blame the user".
In this case, however, it's not a case of general misinterpretation or misunderstanding. It's a case of the law creating very strong -- like significant-millions-of-dollars-on-the-line strong -- incentives for every significantly-sized company to harass every visitor. That's a pretty huge flaw.
It sounds like your response is basically "well if they aren't doing anything wrong, they have nothing to fear! just go to the tribunal and prove that every cookie is innocent." And in that case, please refer back to pembrook's quote above.
I don't have any first-hand knowledge here, but my guess would be that the corporate lawyer's recommendation is always going to be "just get consent for every cookie". The alternative is to risk lengthy litigation over whether specific cookies required the consent. If they ask every time, they can avoid that nightmare.
Because of this, the notice doesn't really serve any purpose of a signal of sysop goodwill. Virtually every business large enough to have lawyers will add it where there's the possibility it'd be required, regardless of the cookie's intention.
Well-intended law that causes many negative side effects is still bad law, just as well-intended software may very well still be bad software.
Presumably SCOTUS would say that an effectively-infinite timeline is not "limited" within the Constitutional definition of the word. Eldred v. Ashcroft basically tried to argue that continual decades-long extensions amounted to this, but the Court was not convinced.
I would say that backlinks are still a hugely important part of "SEO" (with or without the scare quotes).
Companies run things called "Private Blog Networks" so that properties under their control can backlink to each other and get the PageRank bumped. Discerning PBN's place on the spectrum between Public Relations and just outright "link buying" basically depends on how charitable you're feeling that day.
This is the shtick of every big SEO business: "Of course SEO doesn't work, so we don't do SEO! We optimize your position in search engines through good old-fashioned $UNTAINTED_TASK_NAMES!" The point is that it's activity explicitly targeted at gaming search results, and thus, "Search Engine Optimization".
The only way to make it more difficult for dishonest people to make a buck on this would be for Google to get a lot more explicit about how it formulates its rankings, which, for obvious reasons, they don't. As long as there's no objective measurement or standard, there will be no real way to be sure that the techniques employed by a specific vendor 1) work at all; and 2) are ethically satisfactory. Someone with a backdoor at Google, after all, could make a pretty penny. It'd be naive to pretend like such things are never attempted at an org the size of Google.
People will take advantage of every hack they can to get Google to rank them more highly; as long as that's true, not only will the SEO marketplace thrive, but people will be identifying and exploiting those hacks.
There are plenty of tricks, gimmicks, and zero-day hacks whose effect may be as short as a couple of hours, but indisputably, there are many SEO customers who see real increase in search rankings. That's why SEO is still a thing -- it works, at least enough of the time to make it a worthwhile risk.
If you ignore the business's desire to dominate Google results, then yeah, it's no surprise that someone eventually recognizes and attempts to fill the gap. It's best to address these inevitable interests directly so you don't get cut out from the process.
I don't know, it just doesn't feel like there's a ton of risk of "non-profit board member" becoming the next gold-rush degree track.
tl;dr: 7-2 as long as there is some type of time limitation, Congress is free to extend copyright terms.
The sad thing is that you often have to play the game defensively -- I've seen semi-decent organizations end up consumed by the 80% overweight departments because bigger departments end up with all the advantages just as a function of their size, even if they're almost completely worthless. Have to keep pace with the useless hiring just so they can't say "well it's our smallest group, only 5 guys", etc.
Minikube: https://kubernetes.io/docs/tasks/tools/install-minikube/
Alternately, you'd take advantage of $CLOUD_PROVIDER's initial signup credit and start cloud instance equivalents.
Nowadays most things have good virtual environments floating around (you can even download virtualized mainframes if you want). A little bit of time tinkering with such environments will take you surprisingly far -- especially in fields like network engineering, where even most professionals don't know how to experiment.
Technical topics are indeed both very deep and very broad. The level of sophistication and depth is how you choose your specialization, but that doesn't mean you're never allowed to learn anything else. You should learn enough about each field to know the shores when you're standing there, to be able to communicate with the "natives"/specialists, and to know when you're getting out of the shallow end. This expectation should exist for everyone: DBA, application developer, devops, network, whatever. They should all know the territory and be able to work together cohesively to identify the best place to take something down deep.
Depending on the constraints of the project, leaving the shallows means either a) developing more proficiency directly and getting deeper yourself; or b) acknowledging that you need someone with more expertise in that area to take it from there while you go back to handle things in areas you know better.
The thing we must avoid is "well I'm not a network engineer so I don't look at Cisco configs, sorry". That should be replaced with "well I'm not a network engineer, so I have no idea what's happening here, but it's still interesting, can I sit behind you and learn?"
It's this exact divergence that creates the disconnect. If someone doesn't understand and doesn't have to care about the whole experience, they're going to focus on their side and stop when their side is good enough.
On the other hand, if that same someone is going to be regularly developing the application, making changes to the database, and triggering deployments, they will find a way to make the process flow. They'll make it adaptable enough that it's not a day-long pain any time they need to run a migration or spin up a test DB.
The whole toolkit can and should be available because every piece of the stack opens up new possibilities. You want, and at least at some level, can have, people who know this well enough to make good use of it. Nitpicking over "not my specialization" is the antithesis of a smooth engineering process.
It's mainly an artifact of the way we've broken up degree tracks, and the boundaries that each group is taught to stay inside, lest any particular group actually ends up culpable for a failure.
Make fun of the "full-stack rockstar ninja" all you want, but the reality is that it is possible to have a functional understanding of all of these areas. It's just a matter of having the confidence and doing the legwork.
To the extent that more of your people have a working knowledge of these domains, you'll not only have a better end product, but a much easier time getting stuff done.
There's room for hyper-specialized expert consultants in each field, of course, but the myth of the myth of the full-stack developer exists primarily for political convenience. Most of this stuff is not any harder than the rest of it, and can be learned by anyone willing to sit down and learn it.
I've also been pretty happy with it, and substantive new features are added regularly. There's a couple little annoyances from the design assumption that the user's main interest is WSL, but for the most part, it's been much smoother than the other X11-for-Win32 variants.
Support was recently added for listening on a hyperv vsock, but again, it assumes that you're using Windows on the hardware and connecting to a virtualized Linux. The vsock-win32 driver for KVM is supposedly coming soon and then it will be fun to explore just reversing the tunnel and see what we can get done that way.
In practice, the aversion to stored funcs/procs mostly arises from political concerns. Most devs don't understand databases very well, and in most companies, independent DBA teams and independent dev teams end up burning tons of energy fighting for turf.
One of the advantages of a startup is that the smart people are free to utilize the best tools in the toolbox for the problem at hand, rather than having to conform to the social mores around "don't use that tool because it's under the control of the other team and we'll never be allowed to touch it again".