HN user
Yeah interestingly, woke up this morning, said I was blocked on computer. Phone still worked. Visiting the discord page in firefox works.
Being lazy, but might try reinstalling discord sometime later.
We’re (3Box Labs) releasing the beta of ComposeDB on Ceramic: a decentralized graph database that combines GraphQL, reusable data models, and decentralized event streaming. You can find the docs at [https://composedb.js.org/docs/0.4.x/introduction](https://co..., or learn more at [https://blog.ceramic.network/composedb-is-live-on-ceramic-ma....
In its current state, ComposeDB is focused on letting Web3 developers build fully composable applications: apps that share data models and data so they can scale together and deliver user experiences across platforms that aren’t possible with siloed databases. For example, building DMs that persist across multiple apps, reputation that aggregates across platforms, and content collaboration from multiple different interfaces.
For my involvement, I’ve joined the 3Box Labs team recently. 3Box Labs is responsible for creating Composedb and Ceramic, which is the protocol that ComposeDB leverages to deliver its functionality. I’ve been lucky enough to work on both parts in my time with the company. Previously, I was in the network security and web2 space, and started looking for something which can help move us to a decentralized internet, and hopefully to a place where users own their data. Bonus points, if whatever we build is more secure, and less prone to having my data leaked constantly.
Ceramic and composedb will hopefully provide the building blocks which allow dApps to be more easily built in Web3. Would love to know if you find the project interesting, what things you might want to build, or issues you have using the project.
As someone who grew up in Montana, saying Montana as the location makes me laugh. Might want to add a city, even if you do have remote as an option. Western montana to eastern Montana is 8 hours on a good day.
This is probably the first article on HN I wish I could downvote. Excluding inflation is super disingenuous.
We may be spending more, but it's on the order of 3-5% more (not counting debt spending), with the remainder of the income gain being wiped out by inflation.
I will say the exercise analogy is actually very correct though. Income gain helps very little at all with wealth since it helps very little at all due to inflation.
The project was not promoted as that for a long time. That "view" on what the project was only came yesterday, when yet another security hole was identified and a patch was prepared.
The impact of that patch would have likely caused actix to no longer be at the top of the techempower benchmarks.
I also wonder if expectations were unclear. It now sounds like the focus of Actix was on performance and creativity / cleverness and not on being a mature product. I never heard that before. Maybe even the author didn't even originally articulate it so clearly but discovered it through these discussions.
That's actually my main sticking point on this being mostly on the maintainer. From the actix documentation, releases, and promotion, I never got the feeling that it was _not_ meant for production. Even to the point of the comment "Microsoft uses this in production".
And suddenly, "It's creative/fast/research/whatever"? That really feels like trying to sidestep findings because you don't want to lose your spot in the techempower benchmarks. Even more so, when the documentation, etc. is not updated to reflect this new focus, and there's no announcements about it.
I dont know why they did not do that when it got to that point.
I think most people kept hoping they weren't at that point, and could actually move forward without forking.
Right now, if you want async/await, you either have warp or tide.
Hopefully gotham or rocket gets around to updating.
Maintainers of large projects are not even allowed to have a bad day, to make a brusque comment, or to disagree with a majority -- without someone trying to stir up a lynch mob. It sickens me the lack of balance between the work done by the maintainers, and the expectations of random users.
Sure they are. There's a number of projects out there with a massive caveat on the front page that says "Not for production use". They are then more than free to close issues with comments like "Hey I'm researching a new refcell implementation, thanks for finding this, but I'm more interested in speed than safety at this point."
Actix did not put up a disclaimer, and in a lot of cases, either closed issues/patches without comment, or with a somewhat demeaning comment. It was not just published as a fast and safe production ready web framework, it was promoted as such, so the author should expect patches in that vein.
There were multiple bad actors involved here, but it stems from a maintainer who took issue with anyone finding problems in his code.
1. YOU are responsible for your dependencies.
They not only created issues, they also created patches. That is taking responsibility. They were contributing time and expertise back.
Having a project maintainer then call those patches boring or otherwise disregard them? That's childish. He showed time and time again he would respond without civility when an issue was demonstrated in his code.
Sadly, that led to some comments by people frustrated with the project, since they had likely invested considerable time at least using, if not more. But this was a situation that is entirely avoidable if Nikolay would have stopped promoting Actix as for production use.
Verizon NDR | Denver, CO | Full Time | Onsite (Relocation Available) | https://enterprise.verizon.com//products/security/advanced-t...
Verizon NDR (formerly Protectwise) is the evolution of effective, efficient and accessible network security. Customers need no specialized hardware to rapidly deploy Network Detection and Response in any segment of the modern network — enterprise, cloud, industrial, IoT and 5G — to see all activities and record everything for comprehensive analysis, discovery and action.
Come join us if are looking to work on a very challenging problem, securing some of the largest networks in the world, dealing with a high volume of data, on a very good, agile team, with a great group of peers. We work in an amazing office in downtown Denver, near Union Station, making the commute fairly easy. We have a large selection of great lunch and happy hour options, plus the standard amenities like a kegerator and lots of food.
- Network Capture (Rust) - Develop the next generation of network capture and perform analysis of packets and network protocols. Knowledge of C/C++ and network protocols (IT and OT) is helpful.
- Platform - Processing (C/C++/Scala) - Work on the system responsible for ingesting and processing the captured network data. Knowledge of Kafka, Solr, and Cassandra is helpful. Knowledge of network protocols (IT and OT) is helpful.
- Platform - Storage (Scala) -> Work on the system responsible for storing and querying the captured network data. Knowledge of Kafka, Solr, and Cassandra is helpful.
- Infrastructure (Terraform/AWS) -> Help to enable the infrastructure powering the platform. Knowledge of Ansible, Cassandra, Solr, Kafka, and the JVM helpful.
If you are interested or want more information, please email us at ndr.careers@verizon.com. In your communication, please mention hacker news.
But the results have been dramatic. The company once had
200,000 servers and roughly 60 data centers. Now, it's
pared that down to 70,000 servers, of which 8,000 are
handling the bulk of the load. And they've more than
halved their data centers down to 23.
I'm going with clickbait title. Nothing to see here other than someone getting a temporary savings which we will see as a write off in 5 years.
Verizon NDR | Denver, CO | Full Time | Onsite (Relocation Available) | https://enterprise.verizon.com//products/security/advanced-t...
Verizon NDR (formerly Protectwise) is the evolution of effective, efficient and accessible network security. Customers need no specialized hardware to rapidly deploy Network Detection and Response in any segment of the modern network — enterprise, cloud, industrial, IoT and 5G — to see all activities and record everything for comprehensive analysis, discovery and action.
Come join us if are looking to work on a very challenging problem, securing some of the largest networks in the world, dealing with a high volume of data, on a very good, agile team, with a great group of peers. We work in an amazing office in downtown Denver, near Union Station, making the commute fairly easy. We have a large selection of great lunch and happy hour options, plus the standard amenities like a kegerator and lots of food.
- Network Capture (Rust) - Develop the next generation of network capture and perform analysis of packets and network protocols. Knowledge of C/C++ and network protocols (IT and OT) is helpful.
- Platform - Processing (C/C++/Scala) - Work on the system responsible for ingesting and processing the captured network data. Knowledge of Kafka, Solr, and Cassandra is helpful. Knowledge of network protocols (IT and OT) is helpful.
- Platform - Storage (Scala) -> Work on the system responsible for storing and querying the captured network data. Knowledge of Kafka, Solr, and Cassandra is helpful.
- Infrastructure (Terraform/AWS) -> Help to enable the infrastructure powering the platform. Knowledge of Ansible, Cassandra, Solr, Kafka, and the JVM helpful.
If you are interested or want more information, please email us at ndr.careers@verizon.com. In your communication, please mention hacker news.
Verizon NDR | Denver, CO | Full Time | Onsite (Remote Ok) | https://enterprise.verizon.com//products/security/advanced-t...
Verizon NDR (formerly Protectwise) is the evolution of effective, efficient and accessible network security. Customers need no specialized hardware to rapidly deploy Network Detection and Response in any segment of the modern network — enterprise, cloud, industrial, IoT and 5G — to see all activities and record everything for comprehensive analysis, discovery and action.
Come join us if are looking to work on a very challenging problem, securing some of the largest networks in the world, dealing with a high volume of data, on a very good, agile team, with a great group of peers.
- Packet Processing (Rust) - Develop the next generation of network capture and perform analysis of packets and network protocols. Knowledge of C/C++ and network protocols (IT and OT) is helpful.
- Platform (Scala) -> Work on the system responsible for ingesting, processing, and storing the captured network data. Knowledge of Kafka, Solr, and Cassandra is helpful. Knowledge of C/C++ and network protocols (IT and OT) is helpful.
- Infrastructure (Terraform/AWS) -> Help to enable the infrastructure powering the platform. Knowledge of Chef, Ansible, Cassandra, Solr, Kafka, and the JVM helpful.
If you are interested or want more information, please contact Eric Stevens ( eric.stevens1@verizon.com ). In your communication, please mention hacker news.
I'm lucky enough to have a memory/mind's eye where I can see the problem in my head almost always. I also tend to take time to flush that out in my head before I start coding, attempting to work through issues.
I'd like to think without having that, I'd take the time to put it in a day book.
In interviews, I've typically tried to draw/write out the problem (especially in terms of requirements) to help work through what I'm thinking.
Writing a program is like writing. Engineering a system is not like writing.
That's not to say there's not a lot of bullshit around the terms programmer, developer, engineer, and architect, but there are different skill sets when it comes to programming vs engineering.
I think one of the January Who's Hiring jobs was a company doing Rust, but looking for onsite in Berlin or remote in europe. Maybe one in London as well.
If you want an easy time finding a job, Java or Javascript will definitely accomplish that.
It is not however impossible to find jobs in Rust at the moment. I think January's Who is Hiring post had 5 rust job listings. Rust is still not used in a wide range of industries, but you can find a number of opportunities in crypto, fintech, security, and even a few big data shops.
And yes, there's even more jobs that aren't always out there on public channels. Good reason to attend your local rust meetup.
You can learn and use C++ in 2018 and be perfectly happy with it.
This article is arguing that for safety/security, you shouldn't use it. For the majority of projects that are more complex than Hello World, you'll be venturing out of "relatively safe".
Good to hear. Could use box to get around the static stuff, but given the power of lifetimes, would much rather be able to use lifetimes correctly to not have to box everything.
One other thing that wasn't really apparent but would have made my life easier is a way to use an actor to handle a request, so I could have access to a context for thread related activities (e.g. tokio handles). It feels wrong to just use Arbiter::handle there, especially for testable code.
I'm in the same boat, at least for actix-web. The static lifetimes on the handlers (and I think state) makes some things really painful, but is also part of the reason it gets the speed it does.
The actix library is fairly nice though, but still a few cases where the use of globals and/or statics introduces problems.
I have a sit/stand varidesk. I find myself being lazy with posture when sitting, which leads to neck/shoulder problems. Being able to stand helps this immensely, however I do about 1 hour standing, then 30-45 sitting (meetings, lunch, sometimes work from sitting position). I do tend to shift a bit while standing, and the choice of shoes becomes important.
Definitely would not go back to just sitting.
It's a lot of work to fix this benchmark, which is fairly contrived to begin with. To start, have to adjust every sample to accept a warmup time, then run time (which is likely multiple samples), measuring results in that run time, both speed and performance. And you also have to be careful that the compiler is then not optimizing out the repetitions in the runtime, while still allowing optimizations that would produce the best performance.
Benchmarks would be fine if they could somehow actually compare performance between languages. I have yet to see any benchmarks between languages that are even close to being results that would actually be seen.
Although D may have a fast json parser, this benchmark is a horrible comparison. Really need a better way to do cross language comparisons.
So Burger King has a ratio of 10,000:30,000,000, but it has a lower profit margin. Shareholders can then push for a change to compensation, since their CEO is likely overpaid, or their workers are underpaid.
If this is the case, the only people that should be worried about it are the shareholders and the other people that own the company.
And the SEC is responsible for improving company/shareholder relationships, so this falls under their directorate.
I'm assuming this is a ratio of "pay" not compensation, where CEO pay is their salary, and worker pay is salary or total dollars earned. Essentially cash to cash.
If they plan on having equity included, that will complicate things, since you may have variation in vesting schedules.
It provides a proxy to whether the management is looking to increase worker morale and productivity for long term gains, or inflate stock prices for short term gains. It also provides a way to compare companies within an industry, to see which might be overpaying management, with stock returns varying accordingly.
This is total pay, not salary based compensation.
Total pay includes equity grants, which will increase if the company does well, thus will correlate with stock performance.
The total pay can also be manipulated by CEO's targeting short term stock gains over long term growth, which is why more companies are looking at longer vests or clawbacks for equity compensation.