News for hackers. Stuff that matters.

stringy

Re:Python and Qt simplified on Monday March 28, 2022 @11:26AM (#30831519)
My biggest concern would be lock-in to the license, not lock-in to an old Python version. The nominal cost to get up-to-date right now doesn't guarantee me perpetual updates, right?

I'm also suspect of the misleading presentation on the landing page; nothing in the "Open Source" section says anything about the fact that the author has resolved to let the Open Source version effectively die, while up-selling existing users to the paid version. I respect the approach, and you deserve to be payed for the work, but it would be good to not effectively lie on the home page.

Re:Debian: Transition plan to systemd by default on Monday February 23, 2015 @09:11AM (#9094338)
The resolution does mention there will be documentation on switching to sysv after an installation, so I assume this option will have to be officially supported; it sounds to me as though systemd is simply a default, not a requirement.
Re:Glibc Adventures: The Forgotten Chunks [pdf] on Sunday February 22, 2015 @11:47AM (#9089930)
I find it telling that the recommendations for mitigating these sorts of vulnerabilities include adding some slop to the end of allocations (which I believe will only prove to make off-by-one errors "acceptable" when they are clearly still incorrect; perhaps we will see off-by-two error now…) and introducing more randomization to allocations.

This second point I find particularly insidious because the very essense of this paper is that other attempts at randomization (e.g. ASLR) have been found wanting: as long as overflow is feasible there will be creative ways to access the instruction counter.

I wonder how much performance would degrade if a language with a similar runtime to C but with bounds checking (e.g. Ada or Rust) were used to write this sort of software. It seems like the only reasonable way to completely prevent these exploits, and I suspect profiling would reveal there are still hot-spots where selective optimization could bring performance back on par (if it is not already).

Re:Bash process substitution on Sunday February 08, 2015 @01:23PM (#9017996)
The fish[1] shell also has process substitution (without requiring additional syntax) in the form of psub (which is implemented simply as a fish function; see `type psub` from a fish shell):

  bash$ wc <(grep script /usr/share/dict/linux.words)
  fish$ wc (grep script /usr/share/dict/linux.words | psub)
The sugar in the bash form might be nice, but it isn't required.

[1]: http://fishshell.com/

Re:Thoughts on replacement languages on Saturday January 10, 2015 @06:36PM (#8868388)
Well put! Rust shines in that these sorts of abstractions (channels being just one example) which must be builtin in other languages can be expressed as library types in Rust. It is a distinct strength, not a weakness as this article seems to imply.
Re:Make Your Own Programming Language on Saturday January 03, 2015 @03:30PM (#8831890)
According to RFC 1034[1] hyphens can only be interior to a label; it appears many tools simply follow these recommendations strictly.

The exact wording is: "They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen."

[1]: http://www.ietf.org/rfc/rfc1034.txt