-
Why is there a bandwidth limit on the outq? That shouldn’t be necessary. Maybe it’s just the implementation in pf, but it’s totally not required in FreeBSD’s IPFW.
Point is that for incoming traffic you cannot control the flow of packets so you have to fake a lower bandwidth link by artificially dropping packets to slow down the sender. For outbound traffic you have full control of the sending rate and the ability to detect congestion early so limiting your max outbound bandwidth should not be required.
-
-
Your home router doesn’t know the uplink bandwidth of your cable modem connection to your ISP
That doesn’t matter. The firewall has the ability to detect congestion of the outbound traffic and apply queueing/shaping to immediately control the sending rate and prevent buffer bloat. It shouldn’t need a bandwidth limitation. That’s only required for inbound traffic where you cannot control the sending rate, so you fake a smaller pipe with reasonable overhead (~10%) to drop packets early to slow down the sender and prevent severe congestion/buffer bloat.
All I can tell you is that I am not restricting any bandwidth for outbound with FQ-CoDel via DummyNet+IPFW and I get passing test results every time. I only have to restrict on the incoming. So something is different between your pf implementation and my DummyNet implementation. Does the OpenBSD pf implementation include ECN (Explicit Congestion Notification) ?
ipfw pipe 1 config delay 0 ipfw pipe 2 config bw 220Mbit/s delay 0 ipfw sched 1 config pipe 1 type fq_codel ipfw sched 2 config pipe 2 type fq_codel ipfw queue 1 config sched 1 ipfw queue 2 config sched 2 $cmd 00100 queue 1 ip from any to any out via $pif $cmd 00101 queue 2 ip from any to any in via $pifHere is my test result: http://www.dslreports.com/speedtest/35535303
-
-
-
I find it a little disappointing that most of the reactions here are wrapped around the axle on the particulars of
true, rather than the (imo) more interesting examination of how complexity creeps into our software design and what that means.Also, I wonder if people think that they might have something to learn or gain from someone who has a lot experience in our field and has created successful projects! (Note I’m not making an argument from authority – I’m not saying he’s correct or not, just that we might read it charitably and reflect that he might have something valuable to say before reacting strongly!)
-
-
Maybe a dumb questions, but in semver what is the point of the third digit? A change is either backwards compatible, or it is not. To me that means only the first two digits do anything useful? What am I missing?
It seems like the openbsd libc is versioned as major.minor for the same reason.
-
-
Thanks! I somehow didn’t know this for years until I wrote a blog post airing my ignorance.
-
-
PATCH version when you make backwards-compatible bug fixes See: https://semver.org
-
-
They want a difference between new functionality (that doesn’t break anything) and a bug fix.
I.e. if it was only X.Y, then when you add a new function, but don’t break anything.. do you change Y or do you change X? If you change X, then you are saying I broke stuff, so clearly changing X for a new feature is a bad idea. So you change Y, but if you look at just the Y change, you don’t know if it was a bug-fix, or if it was some new function/feature they added. You have to go read the changelog/release notes, etc. to find out.
with the 3 levels, you know if a new feature was added or if it was only a bug fix.
Clearly just X.Y is enough. But the semver people clearly wanted that differentiation, they wanted to be able to , by looking only at the version #, know if there was a new feature added or not.
-
-
-
Imagine you have authored a library, and have released two versions of it,
1.2.0and1.3.0. You find out there’s a security vulnerability. What do you do?You could release
1.4.0to fix it. But, maybe you haven’t finished what you planned to be in 1.4.0 yet. Maybe that’s acceptable, maybe not.Some users using
1.2.0may want the security fix, but also do not want to upgrade to1.3.0yet for various reasons. Maybe they only upgrade so often. Maybe they have another library that requires1.2.0explicitly, through poor constraints or for some other reason.In this scenario, releasing a
1.2.1and a1.3.1, containing the fixes for each release, is an option.-
-
-
-
Without the patch version it makes it much harder to plan future versions and the features included in those versions. For example, if I define a milestone saying that
1.4.0will have new feature X, but I have to put a bug fix release out for1.3.0, it makes more sense that the bug fix is1.3.1rather than1.4.0so I can continue to refer to the planned version as1.4.0and don’t have to change everything which refers to that version.
-
-
-
-
-
-
I remember seeing a talk by Rich Hickey where he criticized the use of semantic versioning as fundamentally flawed. I don’t remember his exact arguments, but have sem ver proponents grappled effectively with them? Should the Go team be wary of adopting sem ver? Have they considered alternatives?
-
I didn’t watch the talk yet, but my understanding of his argument was “never break backwards compatibility.” This is basically the same as new major versions, but instead requiring you to give a new name for a new major version. I don’t inherently disagree, but it doesn’t really seem like some grand deathblow to the idea of semver to me.
-
IME, semver itself is fundamentally flawed because humans are the deciders of the new version number and we are bad at it. I don’t know how many times I’ve gotten into a discussion with someone where they didn’t want to increase the major because they thought high major’s looked bad. Maybe at some point it can be automated, but I’ve had plenty of minor version updates that were not backwards compatible, same for patch versions. Or, what’s happened to me in Rust multiple times, is the minor version of a package incremented but the new feature depends on a newer version of the compiler, so it is backwards breaking in terms of compiling. I like the idea of a versioning scheme that lets you tell the chronology of versions but I’ve found semver to work right up until it doesn’t and it’s always a pain. I advocate pinning all deps in a project.
-
It’s impossible for computers to automate. For one, semver doesn’t define what “breaking” means. For two, the only way that a computer could fully understand if something is breaking or not would be to encode all behavior in the type system. Most languages aren’t equipped to do that.
Elm has tools to do at least a minimal kind of check here. Rust has one too, though not widely as used.
. I advocate pinning all deps in a project.
That’s what lockfiles give you, without the downsides of doing it manually.
-
-
-
-
-
-
I’m wondering why people forgot about the unit/record separators in ASCII. It’s not as human readable/writeable, but its certainly less fragile.
-
In case you’re wondering what this is, ASCII codes
0x1c(aka “field separator”) and0x1e(aka “row separator”) were reserved for CSV-style tabular output use, the idea being that those codes, being in the “control characters” set of non-printable characters, would not appear in normal output and therefore could solve some of the reading problems in the OP, especially with regard to escaping delimiters.It doesn’t solve the well-formedness problem, so you still have to parse in any case, instead of just blindly splitting on those values.
-
-
I occasionally remember they exist, but they don’t really fit a sweet spot for me personally (nether does CSV, though). What I use are one of two things:
For simple tabular data I use TSV (tab-separated values). This makes things human-readable and also makes it easy to use traditional Unix command-line tools, and has the sole restriction that fields themselves cannot have embedded tabs (in TSV there’s no way to escape a tab, they’re simply not allowed in fields). I could use the ASCII record separators here, but it’d be more awkward to read/write the files, for the only advantage of being able to embed tabs in fields, which is something I rarely actually want.
For anything more complicated than basic tabular data where TSV is fine, then I go to a more full-fledged serialization format like XML or JSON, with well-defined escaping rules and support for things like hierarchical data.
-
-
Anyone know if the Papers We Love Conf talks were recorded and if so, when they will be available?
-
They were recorded. Keep an eye on our YouTube channel for the videos within the next couple of weeks.
-
-
-
Microsoft released it under the Apache 2.0 license.
-
-
paulsmith
4 years ago
|
link
| on:
Kx Systems announces free version of its database software and programming language
This getting started PDF shows some example queries in the q language.
We are: I’m co-founder of Ad Hoc. We came out of the HealthCare.gov rescue effort. We saw up close that if we’re going to make government work for people, it needs more folks like us building things in government on behalf of its users. We’re making better government digital services, such as Vets.gov, and we’re still improving HealthCare.gov. We’re remote-first, and we have open positions in engineering, product, user research, and management. Message me if you’re curious.