Hacker Newsnew | past | comments | ask | show | jobs | submit | justryry's commentslogin

Do we need to? No. Does every large and most small organizations I know do it anyway? Absolutely.


This x1000. If you think Optional, Streams, and lambdas make Java close to Scala, you really don't know what you are missing. Some other big and small things off the top of my head:

- import aliases

- type members

- generic variance that doesn't make you want to gouge out your eyeballs

- generics over primitive types

- fully unified types

- an ecosystem that avoids nulls and exceptions

- pattern matching

- case classes

- everything is an expression

- immutable collections out of the box that most every library uses

- higher kinded types

- macros

Sure, maybe Java will get import aliases 20 years after they were due but I'm pretty sure half of that list will _never_ happen. Combined they are a huge deal for productivity, expressiveness, and safety. Java can't die due to the huge existing investments and continuing to improve the language is the right thing to do, but its really well past time for folks to consider more modern languages for new projects.


NFSv3 is very dead.

I like Kerberos a good bit and I think the complexity of running an LDAP/Kerberos infrastructure is greatly over estimated, but it is disappointing that none of the theorized alternatives ever really appeared. Last I read, LIPKEY was the only serious contender and there were some security concerns that got it nixed.


With a house like that, you're probably doing a fair bit of entertaining. You're going to be glad you have those extra bathrooms when you have 60 party guests.


This is one my favorite features of the language and I believe to be fairly unique. It can make for some slick and safe state machine like code.

I do wish that we had reliable RVO so that this could come at zero cost.


Dell has been selling current generation AMD since at least mid last year. We have a few R6415 and R7415s at work.


Curious what type of workload you are using them for?

We're a VMware shop so I'd be hesitant to deploy non-Intel just because I don't want to get caught holding the bag in case AMD can't keep their momentum up for the next 5 years when we'd most likely looking to lifecycle the environment.


What kind of workload do you run that relies on hardware? I mean you mention, you use VMware anyway.


Manufacturing is weird like that. We like VMware because we can refresh our compute and storage without downtime, since a lot (almost al) of the applications are not built for HA.


Thanks for the spam!


No, ZoL bypasses the usual page cache.


Is it doing it for mmap though? 2 years ago, it didn't double-buffer apart from mmaped files. Here's a note about priorities: https://news.ycombinator.com/item?id=11697901

Also seems to be solved in this port: https://www.crossmeta.io/another-zfs-port-on-linux/


Given that said port predates feature flags and has no source posted, making any assertions about what it actually does versus claims to do seems premature.


Do cloud providers commonly float cores between VMs? I could see instances like the AWS T family (burstable) sharing, but I had always assumed that most instance types don't over-provision CPU.

If that's the case, my CPUs are likely pinned to my VM. I could still have evil userland apps spying on my own VM, but I would not expect this to allow other VMs to spy on mine.


Sharing CPUs is not the point, as long as you are sharing physical memory with other tenants, you are vulnerable (although exploits are much harder when attackers have to cross privilege boundaries).


> Sharing CPUs is not the point, as long as you are sharing physical memory with other tenants, you are vulnerable

Not to these vulnerabilities. These are attacking memory that is "in flight" within a processor.


I don't think many cloud providers explicitly pin the VMs to the cores even if they don't over provision the servers.


I haven't seen anything indicating that the operation or repair process requires some sort of online authorization.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: