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

What is 'insane' here is the shear level of entitlement displayed here, including lumping a niche, free, volunteer supported service in with billion dollar, for profit corporations and demanding they pander to your inflated expectations.

Wild.


It doesn't matter who or what the service is, how much they have, or whatever else. They created a problem and now users have to pay for the inconvenience by emailing(!) specific details that could be captured automatically through web logs: OS, browser, IP address. It's ridiculous.

> details that could be captured automatically through web logs

You can't be serious. Are you ok? The entire point is that they're trying to tell bots and humans apart. They're trusting email (and how you write your email) as a good signal that you're human. What are you talking about getting it from the log? The point is to correlate. How do you expect them to know who you are in the log unless you give them that info?

> They created a problem

No, they're dealing with a problem, and compromised that some human users may unfortunately get blocked.

> and now users have to pay for the inconvenience

You don't have to anything. You can just not use them. They don't owe you their service.

Somebody is handing out free apple lollipops, they ran out, compromised on giving grape ones, and now you're complaining you're being forced to eat a grape one and you don't like grape. Don't eat it.


If we're looking at 'future' filesystems, is fragmentation really an issue in an SSD world? Not that there isn't a lot of spinning rust (and will be for quite a while), I don't think it's unreasonable to assume "most block storage is going to be SSD in the future" when allocating resources to priorities.

The day I can furnish my NAS in SSDs for roughly the same price as HDDs probably won't come before any current filesystem is obsoleted for some reason or another, methinks.

Probably true. My bad.

Fragmentation in ZFS wastes a lot of space. So it doesnt matter if it's SSD or not.

You're right...I didn't think that through.

Now at the risk of over generalizing

And yet you couldn't help yourself.


The smart engineer always reads the errata carefully.

MS-DOS 1.25 supported 8" disks. I think 2.0 still did.

MS-DOS 1.25 supported 8" disks. I think 2.0 still did.

MS-DOS didn't have built in support for 3.5" drives until version 3.2.

I'd try to contact Assetnote. Most (sadly not all) managed vuln scan companies are pretty sensitive to scanning stuff that doesn't belong to their client and could expose them to liabilities because they don't have permission.

Yeah, I'll try to do this, but I can't find anything better than the generic contact form.

Try search on LinkedIn. Often turns up folks who work there who you can reach out to.

Oh, and be sure to include "you're scanning a pool address so you're probably scanning a lot of other sites that don't belong to your customer". They should know it's potentially not one little web site.

I'll be honest...I never really 'got' the PDP-8. It's a great example of what really, really smart folks can come up with when you have a very limited transistor budget. The ISA is limited and quirky (aka 'strange'), there's not much memory and it's relatively slow, but a huge amount of serious work got done.

OS/8 and TSS/8 are the 'common' OS. ASM, FOCAL, FORTRAN & BASIC were popular programming languages. You can find images lots of places. I don't guess there's a lot of 'canned' software, as the PDP-8s were more targeted at roll-you-own software. I personally think the most interesting things about them was the many places they were used as controllers for other things, like manufacturing machines and laboratory kit. Not very amenable to a home lab, but they have a very dedicated following in the classic computer world.


If I recall correctly, Oracle best practices back in the day (waaaay back) was always put the DB on raw partitions, which caused us some issues with existing tooling. I've been fortunate enough to not have to pay attention to Oracle best practices in quite a while.

High performance databases still use raw I/O. You get much better control of data placement and write ordering, without filesystem confounders. With traditional spinning rust being replaced with SSDs and SMR it can be even more important.

You may even have different firmware on the disks / disk controllers for database disks.


Sure...pretty clear there's a use case. I just recall our ops folks having to retool some of their playbooks because of the assumption there would be a standard filesystem on every active slice.

Fortunately, the whole "load a particular firmware on the disks" wasn't new. That was something some of the HW RAID vendors recommended.


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

Search: