Hacker News new | comments | show | ask | jobs | submit login
Red Hat discloses RHEL roadmap (techtarget.com)
53 points by sciurus 1609 days ago | hide | past | web | 20 comments | favorite

Blogspam for http://searchdatacenter.techtarget.com/news/2240185580/Red-H...

Downvotes? The only thing on that LWN page is a description of what you can find if you follow the techtarget link. There is literally no new information or even commentary on the page.

LWN is hardly blogspam, although I agree they don't add much to the story in this case.

I actually tried to submit the techtarget.com link first, but the story was immediately marked as dead (see https://news.ycombinator.com/item?id=5876710). Perhaps HN considers techtarget to be spammers.

Techtarget is worse than a spammer. They are a virus... you sign up for some whitepaper, and they add your to a gaggle of different lists.

Almost as bad as Computerworld.

Actually, this does qualify as blogspam in the world of HN. The most likely reason is that the domain (lwn) is well known.

The truth is, the definition of blogspam is dependent on the moods and biases of the moderators.

lwn has its own (paying) community, and the OP link is speaking to it.

Look at its content. Within the first sentence, it clearly links to what it's talking about, saying "Hey, there's some thing here that may interest you."

It goes on to cite an excerpt as an example of what interested the lwn poster.

I would qualify this more as "conversation" than "spam". Spam would regurgitate the linked content wholesale while probably omitting or burying the link to the original source.

I venture that people here on HN are further reacting negatively to the "blogspam" characterization because many of them are well and long familiar with lwn and have a good amount of respect for it, based upon its quality content (much original) as well as its finding a sustainable model while delivering such.

I'm not debating whether lwn is really blogspam or not. However, by HN's moderators standards, it would be classified as blogspam. It offers nothing more of value over their original piece (even if it's narrowing in on a specific subject).

Well, that's a fair point.

"The last thing we want to do is disrupt our customers' workflows." I'm glad to read this.

I had a customer, a minimal English speaker, who had trouble with that phrasing.

"The last thing I want to do is leave your data center with inadequate power or cooling", I said.

"The thing last? You want to do this at the end of our project?" he replied ...

I have always wondered how a demo of Gnome 3 would go down with the IT manager of a customer with a large desktop estate. Pretty obviously the customers asked about retraining time &c.

I say this as one who uses 'modern' Gnome every day on my desktop, but who has been involved with staff training on new applications before.

The default of XFS for filesystems is interesting. They mention the target of enterprise customers. Is Centos likely to also do the same where I would imagine the vast majority of deployments are for smaller environments such as virtualization?

The issue is that over the lifetime of RHEL 7 (2014-2024) disks will grow to tens of terabytes. ext4 can't cut it -- even with extents, fsck times would be phenomenal. You need a filesystem like XFS which was designed from scratch with that in mind, and which is mature (unlike btrfs), and doesn't have licensing problems (ZFS).

Will there be an ext5? https://www.google.com/search?q=ext5

Thanks for the response. I wasn't aware of the performance for xfs_repair. But aren't the customers who are using RHEL(paying for a subscription) also the same customers who would more likely offload data to a commercial SAN/NAS and rely on their underlying filesystem? Obviously, not in all cases but I would think big data needs would be handled this way.

Some of their customers certainly might, but all? I don't know RHEL's pricing, but I have seen/heard of shops that license RHEL but could never afford a commercial SAN. They probably have very striated pricing tiers; remember, "support" is one of the biggest value-adds of a RHEL subscription, and a little company can get away with less support.

I'm rather hoping they'll offload it to Red Hat Storage :-)

But my point about "tens of terabytes" was more about local hard drives, not about big data stores.

Well, as long as there aren't any more data-eating bugs like with thin provisioned LVM in RHEL 6.

In that case, xfs_repair did abysmal job in coping with the data corruption, which didn't quite provide confidence.

We pay for RHEL subscriptions but do both. We have large NAS systems but some machines, like our NFS servers, also have large internal RAID setups. We have bumped into EXT3 max file system size issues in the past and had to use XFS on some hosts.

The software collections feature sounds really interesting. There's workarounds, but it still isn't fun to deal with getting modern versions of fast-moving projects (Python, Ruby, etc.) on an OS designed to last for over a decade.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact