-
awalton
4 years ago
|
link
| on:
Theo de Raadt explains road maps for Windows, OpenBSD and Linux (Re: Thanks for ACPI)
Another in a long line of Theo de Raadt trolls.
Where does he think virtually all *BSD drivers come from? Oh that’s right, they’re ported from knowledge gleaned from Linux, or often, share the same code that was developed for Linux.
-
I disagree, this not how driver development works on any platform.
There’s the kms/drm graphics stuff (which is intentionally MIT licensed so it can be used in BSD and elsewhere), but otherwise there’s not some mountain of unattainable knowledge or code to glean from Linux. Hardware reference information, vendor reference drivers (which could be Windows, Linux, or BSD), talking to vendor engineers, and bit banging and reverse engineering are how drivers are birthed.
Read http://en.wikipedia.org/wiki/Theo_de_Raadt#Free_driver_advocacy and the section below it. OpenBSD’s ACPI stack is one example of clean and fresh engineering.
-
-
Many companies rely on OpenSSL in their products. They would be hurt by this. The alternative would be to give them the funding they need.
-
Caveat emptor, most of the entire FOSS world barely maintain old releases, why should this project be any different? His response on the mailing list is how this is handled in practice:
I don’t know - for a start, just because the OpenSSL team don’t support it, that doesn’t mean others can’t backport fixes.
If you can’t do this, don’t use old software, or choose vendors that navigate these waters for you like FreeBSD releng or RHEL to base your product on.
-
-
-
-
Favorite right now: http://t.co/5ovIst3bkr
Good mix: https://soundcloud.com/hybridsoundsystem/hybrid-summer-vibe-2014
-
-
I had a very similar experience while building Play web applications for the past couple years. I still consider myself a beginning Scala programmer, but I’m able to use it effectively and it’s made me a better programmer in other languages. I still use Scala with some trepidation; I’m not sure if it’s a long term evolution of languages, or if it will wallow in features the way C++ has, but for now it’s my favorite way to build web applications.
-
It is a bit sad. I think old hardware is fun and worth preserving, but there is a point in time where it becomes impractical to maintain newer software and a lot of history is wrapped up in the proprietary software too.
Check out the pictures of the mvme88k at the bottom of this page, it’s pretty cool looking http://www.openbsd.org/mvme88k.html,
It looks like the 88k arch will live on in some other ports, but OpenBSD has retired all 68k archs.
-
I was curious about “Why not postfix” and got a pretty good answer here: http://www.reddit.com/r/BSD/comments/2097kb/openbsd_switches_to_opensmtpd_by_default/cg1h4rj
Basically - due to the IBM Public License
-
One of the reasons I really prefer strongly typed languages is that you can slash code and move it around aggressively to clean up style and split things off into other files. Or perhaps change an interface or even dependency.
If it compiles, there’s a high likelihood it still works.
I’ve found doing the exact same thing in languages like Python and JavaScript is an absolute nightmare. Here, trivial unit tests would help get coverage of the code, but they are substantially more work than simply using the typed language.
My tests in typed languages tend to exercise actual data or string input and are much more focused. In dynamic languages, I’d rather not even write tests because it just feels painful and monotonous to test every function.
-
I think you need tests even more in a dynamic language… although I tend not to aim for LOC coverage, but business rule coverage. If you can meaningfully change the behavior of your application, it should break a test.
I don’t think testing getters/setters in dynamic languages is part of sane TDD. And tests - not blind, rabid, fad-driven tests, but thoughtful and carefully selected tests - can give you some of the same security that the type system gives you in Java/C#/etc.
I’m primarily a Ruby guy, and I write plenty of unit and integration tests… and generally, I find that if refactoring causes me to break so many tests that it’s a lot of work to fix them, then they were either redundant, badly written, testing at the wrong level, or in some other way sub-optimal. As I’ve written more Ruby and more tests, I find less and less often that I’m stepping on my tests when extracting code, refactoring, etc. YMMV.
Edit: and I like to unit test my JS this way too, with Jasmine.
-
-
-
One of the most interesting remarks I’ve seen about OCaml — which I don’t fully understand — is that using it properly involves “encoding your proof obligations into the type system”. Which is to say, I guess, that you choose the way you use its type system to verify that much of the program’s functionality is correct, too.
In dependently typed languages, I am given to understand that you can prove arbitrarily complicated things with the type system, but dependent typing systems are not (ever? generally?) decidable. OCaml’s type system is decidable.
-
-
-
The analogy is a bit off as different languages, libraries, and frameworks are like different instruments and where you fall on this spectrum does say a lot about the type of problems you can solve. As a developer, you can be a composer rather than a player and use different instruments to achieve the sound, tone, mood, etc that you are wanting to set.
Case in point, if you only know PHP, you’re quite limited to the types of applications and depth of thinking. There are a lot of people that fall in this category. I’d much rather wrangle gear fetishists and language lawyers into submission than deal with one language programmers.
-
Sure, one-language programmers are the other extreme. The author isn’t referring to people who are willing to try new things, he’s talking about people who expect the shiny new thing to make everything better by compensating for their lack of skill. If you give a skilled musician a better instrument, their playing will sound better. If you give a better instrument to a novice, they’ll probably still sound like crap.
-
I remember when I read the STL paper in 1996, I was really excited, and I had a bunch of programs I wanted to try to write in this new paradigm of generic programming. But it turned out our compilers didn’t really support C++ templates that well yet, so the STL didn’t really work yet. Rather than write the programs in some less DRY or less efficient way, I decided to wait until the compilers were ready.
I never wrote the programs. Of course.
-
-
I’m surprised the less code base is so bad.
Is the original source code from a BSD tree? I’d imagine the GNU’s less is pretty well done, thanks to their coding standards. (Though using that code would be unlikely, due to licensing.)
I’m laughing quietly to my self about your expectation of GNU code quality.
The same less is used everywhere, doubly GPL and simplified BSD license: http://www.greenwoodsoftware.com/less/index.html
It might also be worth noting that less is not a GNU project.
But yeah, coding standards != quality.
I’m not; old c code had to do some pretty horrendous things in order to be compliant with all the varieties of platform and compiler out there. never had to deal with it myself, thankfully, but I’ve seen some pretty scary codebases.
You may find the comparison between different implementations of echo interesting. GNU’s implementation looks bizarre. I don’t know how much of this complexity is justified though.