None of those are net neutrality, but all of those are things that are prevented by the presence of net neutrality.
Net neutrality is currently enforced because ISPs are regulated as "common carriers", meaning they can't intentionally prefer some traffic over other traffic. The vote on Thursday is to reverse this regulation.
If ISPs could prefer some traffic over others, they could do any of the things that you suggest, enabling censorship.
Sorry, I edited it to indicate that those were things that may or may not constitute an NN violation.
>all of those are things that are prevented by the presence of net neutrality.
How is 2)? If you're penalized by total usage [A], irrespective of source or type, that seems pretty neutral. Whether it's a good policy in general is debatable, of course.
(That's another problem with the debate: that "NN violation" is casually equated with "imprudent policy". If an ISP throttles everyone to 1 KB/s, then, yeah, that's a jerk move, but it's definitely content- and source-neutral.)
>If ISPs could prefer some traffic over others, they could let do any of the things that you suggest, enabling censorship.
That doesn't follow. Let's say they lay down some new expensive pipe for some link in their network, on top of what they already have, and then allow anyone to pay for access to the faster pipe. Data continues to get through at the pre-existing speed if you don't pay. How is anyone being censored?
ANd if you find that objectionable, how is that any worse than toll roads or even e.g. convenience stores, where you pay more in order to have a shorter checkout time.
[A] In this context, I have in mind something like "charging more for users who download more than X bytes, weighted by time of usage" or "slightly reallocating the pipe in favor of lighter users at times of peak usage".
>Is the definition of censorship. ISPs could just choose to not let anybody access their competitors' websites, for example.
You're changing the example -- the scenario was allowing transmitters to opt to pay for the faster link. Packets would still get through at the same speed as e.g. today. It's not blocking them wholesale. At most, it's favoritism, and downloaders still get the data at a reasonable speed as under the pre-upgrade terms.
And the example involved a simple "did you pay?" structure, which is otherwise neutral. It would be a different story if favored sites got the fast pipe without paying, or if only some favored sites were allowed to buy the fast hop at all. But this example doesn't have that.
Prudent policy or not, I don't see how that comes close to censorship.
Do you say it's "censorship" when an activist wants to drive to other activists' houses to plan subversive activities, since it takes longer when you don't use the toll roads?
I can't be changing the example if I'm quoting you.
I am not discussing the presence of fast lanes right now, which have their own problems. I'm talking about the literal prevention of accessing specific data because your ISP decides you aren't allowed to access it.
Without net neutrality, if my ISP sees I'm trying to access a political site that they don't like, they could just make half of all those requests fail. If they like a particular political candidate for office in my area, then they can prevent me from accessing all the other candidate's sites or reading a news story about a positive thing the other candidate did.
This is absolutely enabling censorship and yes we are discussing different examples but I do not need to demonstrate how your example is censorship when another example (that you said was a possibility!) does, if I am trying to demonstrate how this enables censorship. This is not a case of (All things prevented by net neutrality) but (There exists a thing prevented by net neutrality) that enables censorship.
I'm sorry -- this no longer feels like a productive discussion. I described two scenarios: a) one where the ISP deliberately throttles sites with views it dislikes, and b) another where everyone gets the normal speed but some may pay more for faster.
You claimed that any non-neutrality would permit a). I disagreed and gave an example of someone violating neutrality by doing b), where all views are still transmitted, but some have the option to pay for faster transmission.
In every reply, you changed the example back to a) and insisted you were quoting me. That is not responsive, and I cannot justify further engagement unless your replies can more narrowly address the scenario that I was actually talking about.
a) is the only example anyone is seriously worried about. I don't think anyone in their right mind thinks that Comcast or Verizon will make special pipes that are faster than what we have today and keep the "slow" pipes to match the speed we have today. Obviously they will instead call what we have today the "fast" pipes and will throttle (or block) everything else. I would bet my life on it.
Shiny is missing a lot of desirable features (full-screen, window positioning, disallowing window scaling) and is no longer being maintained, unfortunately.
If you need this, you can write type assertion lines in a var block of the interfaces that you explicitly want to implement (and this will throw compile time errors if they don't).
It isn't always as simple as setting some environment variables. None of the projects I work on will compile when told to compile for another OS_ARCH because of the dependencies they have.
C was designed on a PDP-11, a computer much more powerful than the mainframes where Lisp was already running since 10 years, so Lisp implementations were already quite good for most tasks by then.
While C designers were trying to create UNIX at AT&T, Xerox PARC was busy creating Smalltalk, Interlisp-D and Mesa/Cedar.
Other companies were creating Genera and the Connection Machine,
In the end Worse is Better won, because the machines were too expensive for most pockets, normal developers could not grasp Lisp, mismanagement from those companies and UNIX was kind of cheap when comparing prices, with source code available almost for free (AT&T was prevented from selling it early on).
And these figures aren't using the SBCL Lisp compiler which should currently be faster than the one cited.
You are correct, it wasn't designed to compete against C. And it has a garbage collector. But make the right choices and a compiler like SBCL can produce surprisingly "clean" (optimized) machine language code.
Common Lisp has some very fast implementations (I think SBCL is the fastest) and it was designed to be a systems language. It can be optimized to be as fast as C.
Sorry if dumb question but how is this possible when it's garbage collected?
Now I really feel like I need to learn a Lisp though.. Is there a certain Lisp you would recommend that's practical enough I'd use it for projects? Racket?
Just check the hardware capabilities of systems having Lisp 1.5 support, several years before C was created.
Lisp is not only manipulating lists, it grew up to natively support all relevant data structures, including primitives to handle systems programming tasks.
Regarding GC and systems programming, there are plenty of GC enabled systems programming languages, the main point is that they offer features to control the GC and also do stack and GC free allocation if required.
Some examples would be Mesa/Cedar, Modula-2+, Modula-3, Oberon, Oberon-2, Oberon-07, Active Oberon, Component Pascal, Sing#, System C#, D
> Sorry if dumb question but how is this possible when it's garbage collected?
On a big or complex system you end up at least doing one or both or two things:
a. Having to manage many temporal (transient) objects in memory. Thus you end up doing some sort of garbage collector, either doing it yourself, or using the facilities provided by the languages, or a library.
b. Allocating fixed big blocks of memory (such as arrays, or doing a "malloc") and then using this block of memory as your storage area, which then you manage.
Usually on C programming you do (b), although you can also do (a), it is not so easy.
Usually on Common Lisp programming you do (a) very easily, but you can also do (b) by allocating an array and a bit more stuff. It is not difficult, really.
> how is this possible when it's garbage collected?
Common Lisp lets you give "hints" to the garbage collector, so you end up with pretty much what you'd have in C but without the manual memory management.
> Is there a certain Lisp you would recommend that's practical enough I'd use it for projects?
Racket is very nice and comes with great documentation, a huge standard library and a very handy IDE. Clojure was hyped a lot so it has lots of libraries, which however might be of dubious quality or unmaintained by now, and it's on the JVM, which might or might not be a good thing for you. Common Lisp is very versatile and "pragmatic", but lacking in external libraries.
They're developing another game with the engine used for MGSV, but you could account that to just trying to recoup costs involved in making that engine. Otherwise I don't know of other console or pc game projects of theirs.
As far as I know there's another MGS spin off they are working on and they continue developing and releasing their annual Pro Evolution Soccer. With the latter my guess is they want a piece of the money-making pie that is Ultimate Team and works so well for EA Sports' FIFA series.
It does say this. One of the last slides says 4% of the additional size came from adding more debugging information, excluding anything to do with the new inlining.
"If I'm understanding the increase is mostly due to the "debugging" info that is added, not necessarily due to more code.
"
vs
" One of the last slides says 4% of the additional size came from adding more debugging information, excluding anything to do with the new inlining"
So no, it doesn't say that it's "mostly due", it says ~25% is due to debugging information.
"Go inlining improvements..." and then "Conventionally, inlining includes ... but Go has been limited to ... until recently. With ... Go now supports inlining in a broader array of circumstances."
Net neutrality is currently enforced because ISPs are regulated as "common carriers", meaning they can't intentionally prefer some traffic over other traffic. The vote on Thursday is to reverse this regulation.
If ISPs could prefer some traffic over others, they could do any of the things that you suggest, enabling censorship.