I made this as an experiment to see if a older style (PHPBB-alike) format would enhance readability of posts on Hacker News.
To me the present style represents a discussion room in which members form nested cliques, which means that a few comments are well heard while many others are ignored. Voting exacerbates the effect, as disagreeable comments are often pushed down or hard to read (light gray text). Finally, due to the tree-style presentation, it's difficult to determine the context for a reply when there is a lot of nesting levels.
The classic forum style, in contrast, simply shows posts in chronological order, along with the reply-tree visible inline, so context is easy to determine. With no votes or light gray text, I find it significantly easier to follow the conversation; YMMV.
The present implementation is rather slow as the API isn't built for the display format I'm using. Give it a sec to load :)
I'm currently working on adding reply/submit functionality. You'll see dummy replies to this post while I get that working.
I have a different view than captured by your A-E options.
1) The climate, or really the whole earth, has some background rate of change, that itself changes over time.
2) On top of that, there is change, ranging from significant to insignificant depending on the area, caused by humans.
3) This will cause the earth to change at a rate (potentially much) faster than if humans were not here.
None of this, to me, represents a problem in itself. The earth before humans, or at any other point in our history was not some ideal utopia. Humans have inflicted colossal change upon the world since our first day -- we've decimated pests, built cities over forests and dams over rivers, created lakes and removed others, just to name just a few. The world we live in today is anything but "natural".
My primary point of disagreement with those who consider climate change a grave threat is the approach. Rather than setting "reduction targets" and "cutting back", we will, as humans have always done, build solutions to problems as we grow. Whether that's investing in improved desalination technology to provide large quantities of fresh water (due to a demand for water), electric vehicles to reduce localized emissions (due to a demand for clean air), or plant a trillion trees to store carbon (due to a demand for lower temperatures), the key is that for those to be workable options they must represent the growth of humanity, not the decline. There's also vast amount of land in Canada and Russia that at present is undesirable because it is too _cold_.
Humans have survived in horrendously hostile environments and have built upon that the wonderful and wholly unnatural modern lifestyle. Humans have never in history been THIS well resourced to survive despite environmental changes, and I have the utmost confidence we will do exactly that.
I'm the founder of AgMaps (https://agmaps.us) -- simple and fast drone mapping software for Agriculture. Map 160 acres in as little as 15 minutes on your iPad while the drone flies, then locate areas of stress or damage and walk out to manually inspect. High resolution visual and thermal imagery lets you see issues quickly without walking thousands of acres, leading to faster and more accurate inspection.
I'm looking for a non-technical co-founder to bring this technology to market, primarily targeting agronomy co-ops, fertilizer, seed, and crop insurance businesses in the midwestern US. Individual crop consultants may be interested as well. If you can sell software to Agribusinesses, lets talk. devin [at] agmaps.us.
I read that part the same way; for standard remote ID drones, transmission over internet to a USS should be made if possible, but as long as the drone can continue an ADS-B like (but specifically NOT ADS-B) transmission it remains compliant. That's the big question here I think, because there are a lot of places you can fly that don't have internet connectivity, such as rural farms where drones are currently very useful.
It's temping to treat this as more of the same "Catalina is buggy, Apple is doomed" news, but note that Mail.app has ALWAYS been less than rock solid. For some reason, it seems to be a prime target for new features and reconfiguration every release, resulting in a lot of churn which unsurprisingly brings about bugs like this. A cursory search indicates a bug about some messages not showing up in 10.8, a Gmail issue in 10.9, VIP issues in 10.11, etc. But hey, we have gratuitous, cannot-be-disabled window animations when replying to a message, so what's a little data loss compared to that?
> that governments need to put some "guardrails" around engineers and the tech titans they serve
No. We don't need "guardrails" at all. We have an existing legal system that works quite well to discourage companies from profiting from ventures we don't like: we simply make those ventures illegal. Companies have been able to make a profitable business out of harvesting personal data, abusing consent, etc., because these things aren't illegal. GDPR et al is the start of laws in this area, but a financial penalty is simply a business cost. If I can make $500B with a 25% chance of a $5B fine, the rational action is of course to proceed.
If there was a law about certain types of consent being legally required for certain types of data, THEN an engineer, manager, or exec can decide to either a) report the violation to authorities or b) become complicit themselves. When breaking these laws comes with real penalties (jail time, not fines), then the business can choose between a) do something illegal and government puts everyone in jail and takes all assets or b) don't do something illegal, which is exactly what we want.
Bottom line: No special regulation is required here. Simply make a law extending the personal data productions afforded by existing regulations and let the system do its job.
This is better than most of these "tips for a good life" lists, but I feel like it too misses a certain level of overarching consistency. Almost every item has a situation in which the "correct" thing to do is exactly the opposite of what is recommended. How do you make that decision?
As with all of these lists, I always wonder whether this is what the author thinks now, after attaining success, or if these principles are what they relied on during the process? Or perhaps even what they wish they did now that they have more time to think about it?
A commenter below mentions "life is not an optimization problem" -- but isn't it? You're fundamentally making decisions every day that balance your constraints against your goals, interests, and passions. If you just let your life go by without making some real decisions, won't you just regret what you didn't do later?
The reason you have to optimize like this is because a lot of these principles, should you attempt to leverage them to make a decision, provide contradictory advice. Part of this is due to the subjective terms (ie, definitions of extreme vary), but if you're going to use this list as a template or an inspiration, eventually you have to resolve what these things mean to you. I certainly haven't figured that all out and don't expect I ever will; I don't see how anyone could without having experienced all possible things.
All that being said, there are definitely some items that are clearly beneficial and don't put you in decision making paralysis, such as 18 or 24. But there are others that leave me more confused, such as "Don't waste time" or "Don't worry so much". How am I to know if an activity is time wasted until after I do it or if worrying is excessive or warning me about a real issue?
Finally, if you don't identify as neurotypical, what items apply, don't apply, or apply differently? How do you live your life if what everyone else says to do doesn't (seem to) work for you?
Not trashing Sam's thoughts here for sure, but I've read dozens of these things and never came away without having more questions then when I started.
I can offer a personal anecdote here on my experience with code reviews, on both sides.
I was the primary architect and reviewer for a complex real-time mathematical application. When reviewing code, I was pretty much a tyrant: the code had to be correct, well tested, conform to the theory, interface with the rest of the system correctly, etc., in order to be allowed in. I remember leaving some pretty brutal reviews when the proposed design was different than what I thought it needed to be. I thought I was doing the right thing, the project lead thought I was doing the right thing, but maybe I was just making my teammate's lives hell.
In a subsequent job, I was on the receiving end: I was again the primary architect and maintainer, but still needed to seek review from a larger team (my component was part of a larger project they owned). The experience was not enjoyable: reviews sometimes took months (I sure wish I was kidding), sometimes were passthrough "LGTM! I don't understand it at all!", sometimes asking questions like "why is this mutex here" and then I have to spend 3 hours writing up an explanation for how threads and locks work in this case. I found that my mental model shifted: instead of committing small improvements here and there like cleaning up comments or renaming something I just... didn't. I didn't want to deal with a multi-day process of bugging someone to review (they were always busy), dealing with the roulette wheel of comments that might come up, the possibility that I might have to justify some minor thing that I don't even remember the reasoning for. It felt like making a PR opened you up to an uncomfortably invasive inspection, one where the reviewers look down their nose at you and ask you to elucidate why you chose to wear the red shirt today instead of the blue one, as if you're supposed to have some grand unified theory of shirt colors when the actual reasoning is "I thought red would work and it did". How are you supposed to justify why you didn't do all the things you didn't do?
I think an issue is that there's always a different approach that could be used and in a perfect world perhaps we'd iterate endlessly until we found the best one. I've seen plenty of systems that have a design very different than what I think I would do, but as it turns out those systems work too.
I've honestly become less convinced that code reviews are the answer. Is there a possibility for learning reviewer <-> submitter? Of course. Do some teams find code reviews to be hugely beneficial? I would assume so. But I don't know if an organization-wide mandatory absolutely-zero-exceptions is the way to go.
I've noticed a number of sites now are doing something that interferes with the password manager (Lastpass in this case). Common problems are either that autofill doesn't work (even explicitly clicking autofill does nothing), or they put a button in the username/password field that's exactly where Lastpass puts its button, so it's impossible to click.
I don't get it -- don't the sites want users to use more secure passwords? That should mean encourage password managers, unless they imagine I'm gonna remember a 32 character random unique password for every website?
The more I think about it, the more I'm thinking that allowing SSDs to present a higher level API than block storage would be an incredible win. Consider:
- Currently, SSD controller firmware goes to incredible lengths to present something that is not a contiguous block device (due to the way flash works) as a contiguous block device to the OS. Likely this includes a huge amount of logic for storing and updating the mapping between logical blocks and actual hardware storage location. Since the control APIs currently are very low level, the controller basically has to buffer everything, transform that into what the flash needs to do, and then execute, not unlike how a CPU decodes instructions and converts to uops or reorders. Presumably this is quite difficult as early controllers had all sorts of problems such as performance tanking when the disk got close to full.
- The filesystem then pretends that the very non-uniform storage provided by the SSD is actually a uniform block and introduces a layer of metadata in a bespoke format to determine the actual disk locations of files, directories, and their associated metadata. Along with that, it can include lots of very nice extra features such as encryption, journaling, hashing (for integrity and de-duplication), CoW, symlinks, hardlinks, directory hardlinks, etc.
- It seems likely then that were the storage API to be raised to a higher level (files and metadata, rather than block storage), the SSD controller can implement every one of those features with superior reliability, performance, and power usage. We've already seen where software encryption went to hardware encryption -- the result is that the encryption is mostly transparent to performance. What would happen if a file's extents mapping was simply the physical location mapping the SSD controller is already doing? If if could transparently perform hashing on read/write or keep a proper journal of file operations? Handle CoW transparently?
And all of that implemented in a way that those just become standard storage features rather than requiring a certain OS to run.
Key word being "on linux". On the other 99.9% of devices, I have no such choice and the filesystem required by the OS simply presents a layer of incompatibility. Modern OSs all run on essentially the same hardware (same CPU architecture even!) but store the same data in different, incompatible ways. I want the filesystem to join the list of things that are no longer OS-specific.
I want my storage hardware to have a higher level API than "block device". I don't want to format a drive in some OS-specific format, I want a built-in format that I can access from anything. I want this format to be durable, well specced so that I can easily access historical data. I want embedded devices to support richer storage functionality than afforded by FAT32+.
Consider that before S3, we stored files on servers in bespoke ways where we had to worry about permissions and filesystem differences (path too long!) and encryption and durability and a hundred things that we now... don't. Instead we have a simple API with dozens of conforming backend providers, including the ability to do it yourself. Imagine if computer storage experienced a similar revolution?
Absolutely. SSDs have gone from 100+MB/s random (already a huge improvement over the spinning rust of the time) to maxing out PCIe x4. Over the same timeline, what have filesystems done?
- Apple made APFS, which seems to show roughly the same performance as HFS+ on SSD hardware. Some benchmarks show faster, some show slower, but it's certainly no 5X improvement across the board.
- btrfs and ZFS have some amazing features, but remain niche and don't seem to yet have wide deployment. Linux distros seem locked on EXT4.
- Windows has NTFS (and ReFS for the server)
At a consumer level, I care about: a) reliability b) performance c) power. SSD manufacturers so far have delivered hugely on all three. I'd love to see how much more they could deliver by moving a lot of filesystem functionality onto the device. Sure the first few iterations might suck like early SSDs did, but in a few years?
Would be interesting if this evolves into a full filesystem implementation in hardware (they talk about Object Drive but aren't focused on that yet). Some interesting future possibilities:
- A cross-platform filesystem that you could read/write from Windows, macOS, Linux, iOS, Android etc. Imagine having a single disk that could boot any computer operating system without having to manage partitions and boot records!
- Significantly improved filesystem performance as it's implemented in hardware.
- Better guarantees of write flushing (as SSD can include RAM + tiny battery) that translate into higher level filesystem objects. You could say, writeFile(key, data, flush_full, completion) and receive a callback when the file is on disk. All independent of the OS or kernel version you're running on.
- Native async support is a huge win
Already the performance is looking insane. Would love to get away from the OS dictating filesystem choice and performance.
I can't speak for others, but while this is true in aggregate, I'm not personally willing to stake my life on a system that can, on a 1-in-a-million event and with no warning, accelerate into a fatal collision. An otherwise 100% accident-free driving record matters not when I'm dead.
The failure modes of these systems need to be much more gentle: when I'm confronted with an uncertainty while driving, I slow down and pay more attention. I don't speed up until I'm confident that a higher speed is reasonable. This is far far more sophisticated than simply "can I see something in front of me" -- I'm evaluating the probability that I need to stop based on the events I can see happening. If I see a car in front of me slow down and swerve out of the way of something, that means something much more than "obstacle detected" -> "obstacle removed".
I think companies experimenting with licenses like the AGPL are trying to suss out what open source means in the cloud age. When the GPL came to be and software ran on people's computers, there was no way to distribute software that didn't trigger the distribution clause and require modifications to be available under the same license. With the cloud, there is: cloud companies can and do host all sorts of GPL'd software, make modifications, do whatever they want and are under no obligation to release any of that because running a service was not accounted for at the time the GPL was created.
MongoDB Inc's license switch may earn them some hate but I think the bigger issue is what license terms will open source contributors be comfortable with? What license captures the same spirit as the GPL, should that spirit still be desired, as software moves to the cloud? When every piece of functionality, no matter how trivial, can be used by a cloud provider to bolster their closed ecosystem, are the developers that created that software comfortable with a license that allows providers to do so without giving back?
AWS et al. are committing no violation here of course, they are taking advantage of a market opportunity to offer hosted software, some open source and some not. The market is overwhelmingly saying that they value the convenience of having all of these services available at the click of a button and that the closed source nature and potential for Oracle-style vendor lock-in is not a concern.
There's certainly value there and some folks may feel perfectly comfortable contributing to such an ecosystem, as is their right. Others may desire a more reciprocating agreement, and perhaps the AGPL is a first step towards such a license. I think we as software engineers need to recognize just how high we're standing on the giant's shoulders and put some thought towards helping a community that is trying to adjust to the new cloud reality. "Fuck you give me your stuff for free" is unwarranted and not likely to encourage contribution.
I'm astonished at all the comments that vilify MongoDB Inc and then talk about moving to AWS's MongoDB clone. What sort of twisted world are we living in where a company makes a service, tries to sell the service, and then are lambasted when they try to prevent a competitor from copying it wholesale?
Cloud providers have been able to stand on the shoulders of giants, profiting immensely from millions of lines of open source code while giving little of it back, and we seem to be largely fine with this. Will we be fine depending on their services when the cloud providers become the new Oracle, free to raise prices extravagantly when we have no other choice?
If MongoDB Inc can't compete in the enterprise cloud market simply because they are not AWS (as mentioned by threeseed), what should their business model be? Licensing to cloud providers would have been ideal, but the response from AWS in this case wasn't encouraging. By boycotting MongoDB in this case are we telling future innovators that their work will simply be stolen and resold for profit if it gets popular? That scares me a lot more than some project changing their license.
The point I think is that as GitHub adds more and more integrations (git + issues + fork graph + CI/CI + ...) then it's not so simple to move to another service. The vertical is more convenient until you realize you're an Oracle customer all over again.
I use streaming radio to find songs that are similar to a song I like, then look up the artists for some of the new songs that caught my attention. This allows me to find both new songs (immediate win), but artists whose other songs may influence my musical tastes (longer term win).