mden

That's an interesting article, thanks for the link. It doesn't support the original claim very strongly however. It showcases there's a flawed process for obtaining user data (which is still obviously bad) but it's far removed from Microsoft, Google, or Fb directly piping their data over to the NSA.

To be clear I'm not saying there isn't an extensive surveillance apparatus. I'm saying the claim that giant tech companies are willfully providing unrestricted access to user data to the intelligence community is not at all an "obvious" one as claimed and requires evidence. Do you disagree with that?

You're making a wildly different claim than the initial one. The initial claim is "obviously Gmail and such are piped directly into global intelligence databases". Portals for law enforcement which likely require some kind of warrant and very likely have regular audits are not slightly the same thing as directly piping the data to the intelligence community. As for "their inter-datacenter communications were being piped directly", that was revealed by Snowden and you correctly used the past tense "were". Is there evidence that either Alphabet or Meta are giving direct access to their users' data beyond what the law requires?

(Disclaimer, employee of Google, my opinions are my own and all that. I have no info beyond what is public knowledge.)

Chiming in with the rest. Most, maybe all, anti-vaxxers I've interacted with (friends, family, acquaintances) have provided reasons such as 1) the vaccine changes my dna, 2) micro-chips (by an Amazon SWE!), 3) the vaccine only affects people with weak will power (this one was new to me, though it was also laced with God-protects the worthy or something like that). Luckily most of these people eventually were persuaded or to some extent bullied into getting a vaccine. So no, I don't think most anti-vaxxers have well reasoned beliefs that they are holding strong to, though I'm sure some of those do exist.

What do you mean by single screen? There's no technical reason for that to be the case and there are already games that have multiple screens, even past the basic main menu + main game loop ones. You can find multiple functioning and fun, if small, games here https://bevyengine.org/assets/#games.

> it's not clear if it now supports OpenGL

Why do you need opengl when you have support for D3D, Vulkan, Metal, OpenglES, and WebGL2? What amount of the market are you missing?

The reason you don't see many Bevy games is 1) yes, it's new and relatively immature and 2) it takes a long time to make a game. That said, I've had a lot of fun building out a tbs game with it and have been very impressed with the foundation so far. On top of that you get to write in Rust which for me is a huge productivity boost when compared to writing in say C# for Unity, but that's subjective.

One of the potential negative externalities is overwhelming hospitals, pushing out others in need of help.

Calculus is a subset of analysis. It's not really its own subject. Generally what people call calculus is a collection of results that are part of analysis.

Doesn't internet+oAuth+ecosystem essentially cover the metaverse concept already or am I missing the big picture?

> The metaverse will be persistent

That's already the case. Your email, facebook posts, photos, game history, chats, etc are already persistent. MMOs are not at all "the closest thing" to this existing.

> The metaverse will be live

The internet is both live (e.g. twitch) and async (e.g. email) depending on what you're consuming. What is new here?

> Experiences will span both digital and physical worlds

This seems kind of how a lot of things already work, though I can see that VR can push this forward in some respects.

> There will be no cap on concurrent users

Except when there are technical or product reasons right? Pretty much as things are now.

> The metaverse will have a fully functioning economy

I guess this could be improved. General purpose digital trading marketplaces aren't big or general purpose; but that might also be good - centralized markets could take too much profit from the ecosystem.

> The metaverse will have unprecedented interoperability

This is a pretty generic statement, even with the example of fortnite skins being usable in minecraft. oAuth already allows for sharing access to data between different providers. It's a question of the product developers from both sides wanting to create the available interop. Maybe there will be easy to use libraries that handle more specialized cases in the future but what is _new_ here to require a new name?

I still have no idea what the Metaverse is and the "is it already here" section doesn't really explain what is missing. It's just vague concepts thrown into a soup trying to sound cool and I can't find any substance in what is being said. Can someone clarify this Metaverse concept?

I don't buy into the argument that if those people limited their travel and consumption then all of the sudden the non-believers will start believing. There's just no evidence that's an effective way to have societal impact. Not an exact parallel but just because people talk about wanting higher overall taxes and at the same time don't want to pay more than what is required doesn't mean they are hypocritical and it doesn't mean that if they did pay more others would follow.

> You've missed the point and taken it out of context

1. I find the original quote, at least as presented without additional context, pretty difficult to see as anything but nonsensical. You following it up with "Honestly, I think he's right" and "Most of the time the truth itself is not super critical" is leaning into the same nonsensical position even if you try to cover it with additional context of, well actually there's still useful information.

2. This post is specifically about a woman (or in fact several) who have been harmed from this notion of truth not being critical. And you're doubling down on this with a not so relevant view centered around how it's benefiting you and not about the collateral damage. No one is saying perfect information is possible, but in the very least Google needs to be responsible for negatively affecting people's lives and it needs to provide an easy and reliable way to address situations like this.

That's not relevant to the point they are making. CIS is a different major than CS.

Even if that's the case, it doesn't explain why that's bad? Generally that's how progress is made, exceedingly rare is the core of an idea original.

I've done about a 10 mo break after my first job and after my second and it has never been an issue with employment. You're overestimating how much hr and hiring managers care.

I've used it quite a bit but I've had it desync from the server state somehow on multiple occasions making the experience not all that pleasant.

Something I plan on making when free time exists - yet another tool for note organization but with features that I find missing from ones I've seen.

Table stakes:

  - Open source
  - Bring your own client (i.e. you can use any editor as long as data is accessible)
  - Core idea: allows for multiple sources of various types (and makes it easy to add new ones) and then it creates a unified and queryable view over them (via a separate client). Some examples:
  -- Keep notes in multiple files and get a single place I can search over them with annotations of where different pieces come from.
  -- Have source code as a source type. Parse comments that follow the right format to allow smart linking to code for references.
  -- Have the output of tools be source types too, e.g. the output of a grep command.

Bonus features:

  -- Some sort of alerts/notification feature that allows for configuration of trigger conditions
  -- Automatically generated graph view of related concepts / tags / whatever 
  -- Support for multi-user editing with some level of permissioning
  -- LSP support
  -- Editing sources from the unified view (whenever that makes sense)

I think that's rather naive. A lot of work engineers do involves either keeping systems afloat or minor alterations that in cohort lead to a new feature but each minor alterations itself not doing anything meaningful. Evaluating individual or even team impact in those cases is _hard_. Yes, product people or in some cases managers do it but most of their numbers come with five asterisks to cover their asses as they are largely bs.

There are definitely people who are impactful enough and deserve to make bold "I" statements but they are in the vast minority.

Sure but why do you care about the person having a picture... It's Github, look at the code, it's what it's there for.

I think it's more like laws (of man, not nature) than art or math. There are complex rules that define how a computer and a programming language on that computer function. Even if we assume these rules are perfectly defined and not bug-ridden the programmer still needs to understand them and write contracts (code) with no logic errors that can lead to any number of disastrous scenarios such as data-loss, data-corruption, or data-leaking among others.

Take this immense complexity of the computer and the programming language and complex it further with requirements for the business problem being solved and throw in a tight deadline and you have a recipe which leads to the vast majority of code being buggy.

Embrace, Extend, Extinguish. Infamous strategy of Microsoft esp in the 90s.

"Corporate executives have a fiduciary duty to maximize shareholder returns"

My understanding is that that's an oft repeated myth - https://www.nytimes.com/roomfordebate/2015/04/16/what-are-co...

This type of mentality stunts discussion and equally applies to your comment as well as the post. If you truly believed in what you wrote you would simply ignore an opinion piece that you didn't like instead of commenting on it.

Which part of my comment is not true? That corporate culture changes with time? That you can't trust companies like you can humans? I'm genuinely curious with which part you disagree.

It's nice that you can feel morally superior by working at Google (I assume you work there by how hard you are claiming they are good) but please realize that sentiment is not universally shared. _You_ can trust Google to do the right thing but the replies in these comments alone show that there's at least a noteworthy amount of people who are distrustful or at least would rather not have to be trustful of Google. And this also applies to other mega-corporations too.

You not having concerns doesn't invalidate other people's concerns. Trust does alleviate concerns but for some people trusting a corporation is a very tenuous emotion.

"They are not dumb" - and neither are most of the employees of nearly every other company that does unethical things. That's not an argument.

"By the past they have proven numerous time that they have a lot the sense of responsibilities -- as employees, as a whole." - arguable, but even if true companies and their cultures change. You cannot trust a company, especially a public one, as you can a human.

Ideally I would rather the amount I have to "trust" companies be reduced wherever possible and that's only achievable via regulations and enforcement of those regulations.

I think there's also a sort of a tension with this approach of little tasks with little trust and the complexities of modern code. Many small tasks involve a pretty in-depth understanding of a large stack to do correctly. This understanding is not easily developed if the programmers are not encouraged and empowered to explore how things work and having little trust in them is the opposite of encouragement.

So at the end programmers have "small" tasks but they end up being ill equipped to solve and become despondent.

Playing with Bevy and its ECS made me shocked (in a really nice way) how much like a dependency injection framework it worked. Writing a system and simply specifying what resources and queries it needs as function arguments and it magically getting them for me makes it really quick to get to the fun part of writing game code. Are other ECSs this ergonomic?

Still struggling to really get in the flow of where what data should live, but with time it's getting easier. The realization that you don't need all data to be in components also really helps. For example for my game grid I store it as a Resource and inside I store entities I care about such that I can run a normal path search algo.

Overall very impressive and fun project and the discord community is active and friendly.

Const values are inlined at compile time wherever they are used.

Const functions let you run code to define const values. This code will be run at compile time before the const values are inlined.

For example let's say you have a constant for PI but you need 2*PI. You could do the multiplication in const context, meaning the multiplication will happen during compilation and not execution. Slowly more and more of the language is becoming usable in const context so more advanced things can be done during compile time.

Most of the alternate approaches have their own severe failings:

Ask pertinent questions - a lot of candidates are bad at immediate summation and dissemination of information. There are many good engineers who have not learned how to sell their work, themselves, or in general communicate to the intent of a question. This is an invaluable skill, largely orthogonal to writing code, but it's a skill that's often learned with experience. Learning to ask level appropriate questions is hard and evaluating answers consistently (if not objectively) even harder. It is also largely insufficient in gauging programming ability. I've had co-workers who can talk about advanced architecture-y topics seemingly competently but struggle to write even relatively simple code.

Probationary period - I've never seen this implemented (excluding internships which sort of fall into this category) and it certainly sounds like a nice option to have available but I would bet many candidates would be afraid of a short probationary period (say 3 mo) especially if they have to move their family for the job. Being a professional and being told you are on a probationary period is stressful. At many large companies it can easily take more than 6wks to get up to any sort of productivity.

Walk through existing projects - most people (vast majority) do not have any sizable or clean or even "interesting" side project they would want to walk an interviewer through. Unless you worked on open-source for your previous employer (again minority of people) or on your spare time, this is not something you can get a strong signal out of.

Ask them to build something - err, I don't see how this is that different than a coding challenge. And again, not everyone has personal projects ready to be shown to an interviewer. For example, the game I'm coding some nights after work does not look anything like code I write for my employer; there are no tests, there's a lot of experimental and often dead code, functions are not neatly factored and thought out with an eye for collaboration, etc. I would not want to be judged by this code for an interview.

Pair programming - this sounds like a coding challenge but with a more empathetic interviewer. I don't think this is an alternative, just a mild augmentation of a coding challenge.

Focus on ability to learn - companies do this but it's usually considered supplementary to coding ability. Some companies explain their product and try to see if the candidate understands where the value of the product exists or at least where some of the challenges are. This could be spun out into a product type interview or a system design interview depending on intent.

Alternatives to white-boarding or do-at-home project interviews: - Provide a small existing but functional code base and ask the candidate to implement additional functionality. Downside is this takes a lot more effort to prepare and are limiting the candidate in regards to language they want to use. - Provide multiple options for a coding project or question and let the candidate choose which one they want to solve. This would hopefully reduce some of the luck factor of getting a question you know how to solve. - I can't think of any others, but I'm sure they exist

One of the big desirable goals of interviews are evaluating candidates in a consistent manner. All interviewers have biases and these biases vary between the interviewers. Trying to account for that is, I believe, important but also very hard. Using the proposed alternatives would make it even much harder.

Capital One uses microservices with multiple layers for privileging and is "true devops" with devs typically deciding IAM policies.

One of the big issues with microservices is that you need to invest a whole lot more into infrastructure and tooling to be able to run them sanely. Most companies are really hesitant to invest sufficiently which leads to burn out, low productivity, and various ultimately avoidable bugs. This compounded with microservices being inherently more complex you often end up with tangled and messy products that are hard to understand software wise which also impacts security. Having worked at Capital One I think that's certainly one of the big issues at play.

For devops, I personally don't get it, maybe I just haven't seen it done well or maybe when it's done well it just disappears into the background. But expecting all developers to be good at application coding and also have an in depth understanding of AWS security best practices is unreasonable. Something is wrong with the levels of abstractions being worked at.

And then when you click on Success you get this graph (which is a bit sad) - https://shachaf.net/pet.txt

Just want to second how solidly built the game feels. There's definitely a learning curve which keeps on going for many hours (and I think that's a big part of the appeal) and there's some missing in-game information that I've found myself having to look up online - that much is true.

But the UX has incredible amounts of well-thought out polish. Different sized hitboxes for different components, often really favoring playability makes navigating bases really handy. Live map view with the ability to zoom into a location you're not currently near to get a real view of the factory at that point. Unrealistic long reach. Smart notifications on events happening in the base. Graphs diagramming pollution generation and electricity use by factory component type spanning the whole game period. Map layers showing which zones are protected by your defenses, or the extent of spread of pollution, or the routes and locations of your automated trains. And dozens of really useful shortcuts as mentioned.

The game would be perfectly playable without any of these and still be really fun but the love and attention put in by the devs is very clear. And the most amazing thing is seeing all of these things happening all at the same time with thousands of moving pieces updating at 60hz and the game still runs smooth as butter. As a developer I've been very impressed by how smoothly this game runs. And as a gamer I have seen much much simpler games put computers to the test to achieve much less.