1,145 karma · joined September 16, 2016
Me too. I was able to get it from $41,000 to $42,000 by asking for more. I'm up to $48,000 now! Nice job.
From the Show HN rules [1]:
> New features and upgrades ("Foo 1.3.1 is out") generally aren't substantive enough to be Show HNs. A major overhaul is probably ok.
I haven't figured out what the new changes are, if any.
Are you the same as user yann_ck who originally posted this, or just working with him on it? [2]
Historically, pressing the CTRL key would set the 6th and 7th bits of the pressed key to 0.
So CTRL+J would turn both J (1001010) and j (1101010) into Line Feed (0001010).
I suppose some modern systems may have a way to distinguish between these signals, but some systems would not be able to easily generate a different signal for ^j and ^J.
> US authorities issued a federal order to Rackspace’s office in the US ... Indymedia’s hardware located in London ... Rackspace complied, without first notifying Indymedia, and turned over Indymedia’s server in the UK
So is the main difference here just that Microsoft was not willing to just immediately comply with the order from the US government? Or are there additional differences as well?
[1]: https://citizenlab.org/2004/10/fbi-seizes-imc-servers-in-the...
> Turing put this as follows: "an interpretive routine is one which enables the computer to be converted into a machine which uses a different instruction code from that originally designed for the computer".
It goes on to describe how Wheeler simulated a number of capabilities that EDSAC's hardware did not provide. Some more description of that is available at [2].
Finally, I found [3], which includes an actual listing of an interpretive routine for the EDSAC and a more detailed explanation. See page 47-48.
After seeing [3] it's like writing a bunch of EDSAC assembly then partway through, you want to work with floating point numbers, which no EDSAC instructions support, so you use a special code indicating your next several instructions are written for the "EDSAC+Float" machine instead, and they are interpreted that way.
This final document I located was quite interesting.
In the end, I think "interpretive subroutines" are perhaps closest to being like "virtual machines" or "emulators". Because there weren't really high level languages at the time, the concept in their mind is more like writing code for a different machine. It is like a high level language, in that it expands the set of operations that the programmer can use to speak with the computer.
[1]: https://books.google.com/books?id=uflV0_q-FEUC&lpg=PA190&ots...
[2]: https://books.google.com/books?id=AoWrCAAAQBAJ&lpg=PA33&ots=...
Don't forget that the vast, vast majority of computer users are not like you or anyone that posts on this site. They probably respond differently to these types of videos.
- Subroutines
- Modularity
- Unit testing
- Reusable libraries
- Documentation
- `goto`/`return`
- Debugging
The tone seems to place this writing as instructive -- someone who wanted to write a programme at the time could refer to this document for hints at what to do. Very interesting window into the past.
I haven't quite decoded exactly what the modern formulation of an `interpretive routine` is. Is it the same as the layer we would now call the "instruction set architecture" that sits above some "microcode" operations? Where some instructions do more work than others behind the scenes. It also seems to have some relation to "just-in-time compilation", just at a lower level than the current systems.
1. The README.md file indicates "Disclaimer: This is not an official Google product."
2. This site's guidelines prohibit editorializing of titles.
A more appropriate title would perhaps just be "Lullaby: C++ libraries to help teams develop VR and AR experiences." This uses only the text on the actual linked page.
There are many repositories under the "google" organization on GitHub. A great number of them are not "Google products" but just projects that Google employees work on.
What relation, if any, would this type of system have with "persistent data structures", a term I have seen used in some browsing of functional programming topics. Is this somewhat like a persistent data structure until old parts are overwritten ("garbage collected"?)? Is there a flavor of persistent data structure similar to this?
I ended up hacking a bluetooth earpiece into a remote after seeing the idea online. It was 100% reliable over a period of over 2 years.
Having it mounted in the open like that seems like it could have a few drawbacks. I would still be concerned about water damage, even if you don't plan to ever be out in the rain. What about the fasteners you used? Are they rust-proof? Things mounted on my bicycle that have any metal parts seem to wear out over time, and plastics seem to take on some weathering, possibly from sun.
https://github.com/brson/rust-api-guidelines#interoperabilit...
Maybe the checklist should get a more prominent link or notice in the blog post. It took me a while to find it.
> Consistent with the provisions of the FedEx Service Guide, the money-back guarantee is not in effect for FedEx Express packages due for delivery on May 2, 2017.
So I found the section "Money-Back Guarantee Policy" in the Service Guide. There are several sections describing the guarantee and a list of specific limitations and exceptions, one of which is:
> 2. The service failure resulted, in whole or in part, from any of the circumstances described under the Liabilities Not Assumed section.
And in the Liabilities Not Assumed section, the end of item D states:
> disruption or failure of communication and information systems (including, but not limited to, our systems).
---
After all that digging, I went back to the very first paragraph of the Money-Back "Guarantee", which states:
> We offer a money-back guarantee for our services. This guarantee can be suspended, modified or revoked at our sole discretion without prior notice to you.
1. Why do they even need to list all the exceptions and limitations if the "guarantee" can be revoked for any reason?
2. Why is the word "Guarantee" used in the name of the policy? It seems deceptive to offer a promise that essentially means nothing.
I'd rather see it called a "Money-Back Policy" and have it only list the specific cases where it does apply. At least then the customers would have a better idea of what they were buying. It is too hard to figure out what does and does not apply when only negatives are listed.
I was interested in an upcoming conference related to some technology I have been working with, so I decided to calculate what it would cost to attend. The fee to attend the conference was not outrageous, but I would have to fly to the location and find lodging for 3 nights.
I decided I could probably do it for about $1,000 if everything went well.
Then I realized that I would probably be able to just watch the videos on youtube afterward. Since I wouldn't know any of the people in attendance and my knowledge of this technology would barely let me converse with experts, it seems like a simple choice.
So if you're hosting a conference, how do you convince people to spend a significant portion of their yearly salary and miss several days of work instead of staying at home?
Since I haven't used it, I'm not sure, but it seems like it would also help avoid the case of "Can you squash this before I accept it?" leading to pointless delays and extra work.
If you have five different suggestions, should that be five separate PRs to their feature branch? Probably? Or they will just need to modify or rebase out the commits they don't want.
Anyway, I just like all solutions where "doing the work" is encouraged over "talking about doing the work." Often, the doing takes less time for both sides.
If you have a better idea how to accomplish part of a suggested change, you can communicate that more clearly by making a patch and leaving a comment explaining why. GitHub should encourage this and allow the submitter some interface to easily incorporate that patch into his PR.
This is especially useful in situations where the only changes are in documentation or writing rather than code. Dealing with a dozen responses of "s/topy/typo/" should be as simple as clicking a few buttons to accept all the corrections. It would be less work for both sides.
I can monitor and control the power usage of my electrical appliances.
I can control outgoing network requests from my networked devices.
I cannot control what is sent to my network from the outside. It doesn't make much sense to be charged for what someone else sends to me. Even if I shut off my network device, a particularly rude service might just continue blindly sending data my way, running up my costs with no way to opt out.
Typical postal mail delivery is paid for by the sender, not the recipient. It becomes complicated here.
The scenario you introduce is different from the specific line I was responding to. My intention was to show that some more consideration and rework of the idea could bring more clarity. You have helped refine Sam's point and now I understand it better, but as I read it, it seemed like something that should be addressed.
> Consumers generally tolerate that network management for some things is ok, for example, constraining the transfer speed of users at peak times.
I could have a switch to change my water heater to the non-interruptible service if I needed to use it during a time of peak demand. How does "pay more for priority" fit into the net neutrality picture? Is it okay as long as the user is the one choosing which of their traffic is in the fast or slow lane?
I can get cheaper electricity for my water heater if I choose to attach it to a source that can be interrupted at times of peak load. I'm not quite sure this line of reasoning will stand.
Edit: It appears the linked article has been updated since I originally posted this. The new text is:
> You wouldn't accept your electric company charging you different rates depending on the manufacturer of each of your appliances.
This makes the argument much clearer and my concerns no longer seem important.
Absolutely. But as soon as those are required in order to use your library, shouldn't they be included?
> If library A had exposed library B to its consumers as part of a public interface, that would be a breaking change, but it wouldn't be if they hadn't.
Maybe I should have refined my original post. I guess it was way too long.
The hyper crate exposes `hyper::header::Vary`. To create a `Vary::Items` in my program, I also need to `use unicase::UniCase`. See the short example at [0].
It felt odd to me that I was required to have my own dependency on unicase when it seems like an internal issue for how Hyper represents the Vary header.
I have little experience with these dependency management systems. This seems like an irrelevant detail (they look just like strings to me! why doesn't it just take strings!) requiring me to explicitly include an unrelated package. I may have no other need for the unicase package.
Is this a normal thing, though? Since unicase is required in order to use this feature of hyper, shouldn't it just come along with it? Or the Vary item could just use Strings on its public interface so the user doesn't have to go through this extra work?
[0]: https://hyper.rs/hyper/v0.8.1/hyper/header/enum.Vary.html#ex...
I wasn't suggesting Cargo being relied upon by everyone was an ergonomics issue, but instead referring to the description in the remainder of my post.
A couple months ago I was exploring Rust's web server capabilities after seeing the "Are we web yet?" page. I decided to try out the `iron` package.[0]
I was quickly able to serve some basic content, but I wanted to add some headers to the response.
I was able to `use iron::headers::Allow` to add an Allow header.[1]
Next, I wanted a Link header. Link wasn't available but I could get around that by defining a custom header with the `header!` macro. Unfortunately, I couldn't figure out how to get the `header!` macro for custom headers without `#[macro_use] extern crate hyper` and adding `hyper` to the Cargo.toml file.[2]
Then I wanted a `Vary` header. I was able to get that in with `use iron::headers::Vary`, but I couldn't actually create one yet! In order to create my `Vary::Items` header, I needed to also `use unicase::UniCase` and add `unicase` to my Cargo.toml.[3][4]
So within an hour or so of starting the project, my explicitly listed dependencies had grown from just `iron` to include two additional dependencies. The iron package already relies upon hyper which already relies upon unicase.
Here are some questions I am still left with. Would love any responses.
Is it possible for me to use the pieces described above without explicitly listing these crates? If not, why do I need to declare hyper as a dependency when iron is already using it? Perhaps I don't need to, and I was just unable to figure out how to get the `header!` macro from iron directly. My initial expectation was that iron would either wrap or expose every part of hyper that I might need. The same goes for hyper not allowing me to just use the same unicase it relies upon.
How am I supposed to get the correct version of hyper and unicase to match with the ones that my version of iron was sent with? Do I have to go look them up? Can use the latest version of `hyper` even if `iron` is a few versions behind? What version should I be specifying?
[0]: http://ironframework.io/doc/iron/
[1]: http://ironframework.io/doc/iron/headers/struct.Allow.html
[2]: https://hyper.rs/hyper/v0.9.9/hyper/macro.header!.html
[3]: http://ironframework.io/doc/iron/headers/enum.Vary.html
[4]: http://ironframework.io/doc/unicase/struct.UniCase.html