I stand by my statements. Is this supposed to be his Github: https://github.com/ElonMusk Is this a joke?
I don't see why anyone should respect his opinions as a software engineer.
-5 karma · joined December 9, 2020
I don't see why anyone should respect his opinions as a software engineer.
I consider anything less than $170k/yr these days to be insulting, regardless of whether they are FAANG or not. My last 3 non-FAANG position have paid that much / more.
You don't need AWS either. AWS is actually a backwards development of technology in my opinion because it is anti-open source.
It is quite straightforward to lease your own server and/or build your own and colo. You can even easily setup containers on such, or a cluster of them if you desire.
You also don't need a domain name to host a site. Plain IP addresses work fine in many situations. There are plenty of "shady" countries who will let you register DNS and do whatever you want with it.
Just look at the underground pirate community. None of this weak censorship by silencing Facebook posts is stopping them. Piracy will continue to the end of time, because if you have a bit of tech skill there is very little that can silence a person on the modern internet.
And yes, p2p ( without internet ) file sharing is alive and well. Those in draconian environments engage in it. Swapping 12tb drives is quite effective in sharing data.
Own microchips? Yeah we are heading that way. Hence the popularity of Risc-V and various "open hardware". Typically it is sufficient to use your own software stack on existing hardware though.
SV execs can't do shit about public opinion or the underground community.
The free exchange of information is alive and well. It just doesn't live on Facebook or Parler or any of that crap.
It's astounding to me that anyone considers Musk's opinion about software as having any value.
To help stave off the inevitable downvotes you idiots are sure to give me, I'll also address the point itself.
Most mobile devices do not gain a routable public IP address, so some third party server is required to establish a connection between users of a mobile service.
I agree that allowing anyone to run such servers provides more redundancy, but then they would not have control of their own service. Most creators of software want to remain in control of their baby so to speak.
The main reason services go down is not because of lack of computation power but lack of ability to have so many simultaneous network connections.
I think Musk is wrong that the problem is "the servers are doing too much".
In both the Bay Area and Seattle if companies don't at least attempt to get close to these numbers they will not be able to get the best engineers from these areas.
Using an OS such a RHEL gives some guarantees about auditing for vulns being done already for you. You don't have to take on the responsibility for analyzing everything yourself. CentOS historically gives some of the same benefits.
What do you think Amazon uses internally for Amazon.com? They use a variant of RHEL. ( albeit a really old "jankified" version )
I'm not suggesting you run the server over home networking. ( which is against TOS by the way ) You can own your own server and place it in a good Colo facility who are already handling the power, routing, etc.
I previously wrote the management software for a major company that handles configuration and setup of all their data centers. I know a thing or two about what is necessary.
Redundant power and networking with monitoring of both is essential, and also common and easily available in a decent colo. You can of course use a bottom dollar colo that just throws some shit together, but you will, as you say, risk there being vulns in the stack outside your server.
That said, it isn't hard either to setup your own data center from nothing. You need multi-phase power, redundancy, and a number of components that are somewhat costly for an individual, but there are reasonably affordable options these days. You can get 220 in the home if you pay for it. I'd recommend having a commercial location pre-setup with it though of course. Preferably you'd want your data center near a major internet hub and/or with connections to multiple major internet providers...
And yes. I have guards from someone walking away with my equipment. I have a gun and I'm happy to shoot any intruder in the face with it. All my drives are encrypted as well and if there was a breakin they will auto-shutdown...
I own enterprise level tape backup equipment and hundreds of tapes. So yes: offsite backup that is encrypted. The keys are backed up and encrypted themselves.
You can go down the rabbit hole as far as you like. My setup is still more secure than Amazon and the like.
fx doesn't do that. It is primarily just a convenience way for tying things together in the single intended way. You can provide some configuration but it is not via a DSL; it is by making calls to the fx library.
Realistically to do the sort of DI I am referring to with Golang there would need to be a preprocessing step during compilation that generates Golang code.
It is more complex than simply "I just make an interface and make everyone agree on that interfere". Everyone agreeing on the interface to use is very unlikely.
The underlying data in different implementations will be different. This is something Golang fails terribly at because it doesn't have polymorphism.
This is, I believe, why there are so few DI systems for Golang, and most of them are of the sort you are referring to as silly.
The way Golang works, and the reccomended patterns for Golang are somewhat anti-DI.
I do not mean JSON, as JSON is not a good generalized meta-programming notation. People use it that way but it ends up ugly and hard to read.
JSON can be used alright as a configuration notation, but does not represent itself well as a metaprogramming language, since it does not preserve order or allow mixed content. You can get order by using an array of course, but it is much more verbose than the equivalent content in XML or HTML.
You might say, by DSL, I mean "custom markup languages".
It is certainly a different mentality from straight out coding everything.
I think it is important and will grow bigger in time, because low code is a type of metaprogramming.
You don't "need" to use low code stuffs or do metaprogramming, but if you know how and learn it well you can get much more complex things done quicker than coding everything.
The stuff you are objecting to is due to Spring and such seeking to be a type of generalized metaprogramming instead of focusing on custom DSLs. A custom DSL will have less verbosity, not more.
In a good low-code setup, all your logs should go to the "log" module, and there should be very simple configuration indicating where the logs go.
The example is simply the beginning. It can be extended as needed depending on your use case. This is how most things Golang work. You start with the basics and add what you need on a case by case basis.
If you want something with every bell and whistle out of the box, Golang is going to be a disappointment generally as that is not the Golang mentality.
There are of course sufficient frameworks in Golang these days to provide such things though. Hence the article clearly says "standard library" to indicate that it isn't the last word on how to setup a REST service in Go.
It contained no explanation or reasoning to that end. It is purely what it is titled as: An explanation of how to do it with the standard library.
In that sense I don't think there is anything wrong with it. It doesn't make any claims; it simply provides the information it said it would.
Also, one of the main selling points of Golang is that it aims to deliver functionality with minimal additional cruft/add ons. Many of the standard library things are this way and don't provide the "extra stuff" you are desiring.
You mention auth, but many of the frameworks for Golang don't even implement auth and merely provided the ability to add auth if desired.
Logging is a debatable topic because the "standard" logging method is very inadequate, and so each of the various frameworks has to just choose a random logging system to use. ( or several )
While some frameworks do offer the ability to restart without killing active connections / requests, it is a more generalized issue with any service in Golang. It is also best addressed by writing your service in a scalable fashion and doing a rolling upgrade. Stop sending traffic to an instance, wait till current requests are done, then kill it. It doesn't need to be addressed within the service itself.
DNS does WAY more than what the typical user needs it for and services that present it are resultantly much more complex than what is needed for the 99% use case.
The 99% use case: resolve x.y.z to some IP address.
What I think should happen:
1. At each level, a public/private keypair is used to authenticate valid records for the name. Eg: .com has public/private keypair(s) to represent who can sign x.com records. .com owner only needs to publish these. Reliable sources ( ISPs etc ) can then share these.
2. The x.com records themselves would be: Mapping from x.com to IP address(s) / public key.
3. The x.com owners could then publish out their x.y.com records freely and they could be mirrored by everyone.
Unlike the current methodology, there would be far less need to trust where you get the records from. The public/private keypairs should change WAY less frequently.
Agreeably in such a widely distributed system you wouldn't have nice TTL, but that is for the better. DNS records should not be changing that frequently.
Such a new system also should be done in a fully distributed way and NOT controlled by a bunch of money grubbing bastards who make way too much money from records.
It should NOT cost $20/yr to own a record pointing x.y to a number. It's absurd and really needs to stop.
Say what you want, but I enjoy feeling happy, and if I have to engage in a bit of mental convolution to achieve it I'm all for it whether it is a lie or not.
It gives example after example of how we repeatedly attempt to make classical AI work and it fails. The goal overall of the article seems to be to claim that ML is the correct path because hard logic based AI is too complex and will never work.
I think this is a bad view because it doesn't acknowledge that both are necessary.
It is painfully obvious that humans have an internal dialog, and that the subconscious also engages in a sort of thought process involving tokens as well.
There are clearly many possibilities that we consider as people. These possibilities follow something close to logic but heavily influenced by notions that have been built through a non-logical process ( our "beliefs" )
What is hopelessly inadequate is pure neural networks and/or trained ML. To ever approach anything similar to human thought we will have to use tokens.
Doing that is very difficult but not insanely so. Using the word insane implies that such a process is not guided by some predetermined logical system. I agree it is not fully logical, but not that it is insane.
The article is too dismissive of classical AI and seems to imply that those pursuing it are wasting our time.
I'd argue that a good note-taker will be doing the latter automatically.
I also disagree with the claim that note taking doesn't enhance learning. It forces one to pay attention rather than daydream and ignore the content entirely. It would be less tiresome, of course, to just pay attention and not take notes, but it does serve that purpose.
Another purpose for note taking is to pass the notes on to someone not present during the class/lecture/talk. For example: I was paid to take notes for others in college.
Another use for notes is to look back on the notes and verify that you have effectively absorbed the material; studying portions that you don't understand fully.
The article is far too dismissive on the value of plain note taking.
This is an absurdity. Both methods are valid. Different people want different things from the error messages.
This is most commonly addressed in programs using "verbose mode", often with multiple levels of verbosity ( -vv or -vvv ).
Another type of error message which I wish was a required standard is to output structured error messages in the form of JSON containing all the relevant bits of information. It is very annoying to have to parse apart error messages coming from a tool being called programatically.
Mocking objects for testing purposes and swapping them for the real objects is also something commonly done that is helpful.
There is no "real" DI for Golang as far as I've seen. The only DI I've seen that effectively do the sort of thing I am describing are for Java.
I'll agree that it is more likely the cloud providers have more logging and monitoring in place though, and that can make a big difference. On the other hand, cloud providers get far more attacks.
I disagree that hosting and doing everything yourself is not more secure. It absolutely is, especially if you use your own non-standard setup and work hard to prevent easy analysis of your setup.
Example: If you host your own server and only server static web files with no interactivity... and only expose port 443... it is possible to pretty much guarantee the server cannot be hacked and at best could be DDOSed. Obviously hardening measures would be necessary too, and taking care to not expose anything besides pure static file serving, but that can be done with relative ease.
If you use a cloud provider, the attack surface is HUGE. All of them have extensive APIs, with so many possible places where there could be a vuln discovered.
I think it is absolutely incorrect that using a public cloud service is more secure; there are simply too many bells whistles gears bolts shims and everything else.
Q: Describe how credentials are provisioned, managed, and stored. A: Credentials to what exactly? Since I don't use a cloud provider all the data including credentials are safe and secure on the server hosting everything.
Q: If an attacker gained access to an individual developer’s cloud credentials A: The only developer is me. Anything besides what I trigger myself I would notice immediately as out of the ordinary.
Q: What actions could that attacker perform? A: Not much. Externally facing applications are containerized and have access only to the level of access to data that they should. They would not gain any control of the system
Q: How would you detect and respond to the breach? A: I'd notice activity in the logs which are monitored for unusual activity. I also check them manually myself besides the automatic monitoring rules.
Q: If you don’t use a cloud provider: why not? A: They are overpriced and I don't trust them.
Q: Describe how staff authenticate to company services (e.g. servers, email, SaaS products), particularly highlighting your use of password managers, 2FA, and SSO. A: Passwords? What b.s. is that. Certs all the way.
Q: What development practices do you use to protect against the OWASP Top 10?
1. Injection. A: Only parameterized queries are used. Non-issue.
2. Broken auth. A: Only use reliable session/auth stuffs and/or look carefully at the details of how it works. Don't use crap.
3. Sensitive data exposure. A: APIs only expose the data needed and all access is logged and monitored.
4. XML External Entities. A: I don't use crappy XML parsers with such vulns.
5. Broken access control. A: All applications I run were written by myself and access levels only have access to just the needed data. That access level flows to all places data is accessed. Nothing is given access without an associated current valid session and auth level.
6. Security misconfiguration. A: System is hardened. Containers are used. Everything is kept up to date to the bleeding edge at all times. No legacy crap is used.
7. XSS. A: All access is in house. No external entities are loaded period. I trust no one. All entered data is carefully output in a way to prevent user entered data from having influence on code. Eg: No user data is trusted and everything is validated as being, essentially, plaintext.
8. Insecure deserialization: A: No outside entities are deserialized since I don't accept any. Anything that could have been altered by a user, the parsers are all secure state machines which cannot possibly have any influence on the system.
9. Using Components with Known Vulnerabilities. A: I trust nothing, including libraries. I review the code of many many many things. Obviously cannot review everything but I at least choose libraries that are kept up to data and regularly worked on / used by others. I am sure there are 0days present that aren't public yet, but even if they were taken advantage of they wouldn't get access to much.
10. Insufficient Logging & Monitoring. A: All access and operations that affect data are logged. Read access is also logged and monitored to some extent. Describe the steps a developer or operations person takes to push new code to production. Have you had any security breaches in the last two years? If yes: please explain the breach, and provide copies of any postmortem/root cause analysis/after-action reports.
The killer feature set of a messaging system that will allow it to crush WhatsApp, Signal, Session, etc:
* Fully open source ( app, nodes, everything )
* End-to-end encryption ( obviously )
* Rotating keys for deniability. Basically just create time valid subkeys and periodically post the private key to the subkeys. Probably once a day would be sufficient.
* Full message export/import including tweaking and faking messages. It isn't really deniable if you can't show you could easily fake some past messages.
* Fully capable Linux client, so that we aren't forced to use an untrusted and possibly backdoored phone to use it.
* Extra secure time bucketed send/receive if you want to avoid timing attacks on location.
* Hash section bucketed messages along with the bucket by time. For example, if your public key is 4BC56..., you can request all messages sent to 4BC* and get them all, so it isn't then obvious who exactly you are.
* Subkey unique per communication partner. This way gaining someones subkey for a time period doesn't let you potentially capture other packets you know are encrypted and decrypt them too...
* URL based identity. Post your public key to URL; tada that URL can then be used as your identity. Have a bunch of different secure countries host free identity upload sites.
* Group chat which just makes it so you communicate every message to every other partner in the group chat and vice versa. Any other way wouldn't be secure.
* Message size padding to private size based packet matching.
* Automatic sending of periodic messages to bogus destinations. This way it is not immediately apparent if you are sending something out or not. Preferably this would include adding random people and engaging in nonsense chat sessions with them for random amounts of time. Only the client on the other end would know if it is a bogus message or not.
* Message nodes completely wipe all data hourly ( for regular messages ) or daily ( for the daily grouped messages )
* Message nodes all ban any client attempting to download more than a certain threshhold of data. Publish the banned clients publicly. Expose the watchers.
* No registration. Basically anyone should be able to send/receive through whichever node they wish that has available bandwidth. You send an encrypted chunk with a destination ID. Others can download chunks tagged with some hash part of the destination.
* Central "saturation tracking node" that receives saturation from all registered nodes in the system and just publishes a file on a URL for whoever wants it to figure out which node they will use to communicate that isn't over-saturated.
* Can post a set of nodes you listen on to your URL with public key periodically so clients know how to start communication with you. Once established; switch to unsaturated nodes...
The following features are somewhat irrelevant:
* Onion routing. Just connect to the service through any number of other onion routing systems. No need to put all our eggs in one basket. Use a private VPN + Tor to connect to the system. Done.
Parler was banned rightly because they are allowing speech that encourages domestic terrorism. ( such is not free speech and is illegal under US law )
I've hated this about Signal since first beginning to use it. Forcing everyone to use a phone number makes it so much harder to have a partially anonymous way to communicate.
I can't help but feel this was intentional to prevent use by those wishing to remain anonymous. I don't believe they'll ever actually do this.
If they could have they would have done so already imo. Perhaps they are fighting whatever restrictions force them to do this. We can only hope.
My belief is that various governments prevent Signal from allowing anonymous registrations and will continue to prevent them from allowing it.
I expect that what they will allow is something like "you can now register with a gmail account". That is the same restriction since you need a phone number to register for a gmail account these days.
That said, at least they are doing something to try to contribute to lessen the impact of their wrongs.
"Won't fix anything" is true in the sense that is hardly compares to the damage Amazon does to the US economy and housing costs in the Seattle area.
It isn't true in that it is "nothing". I checked out this article hoping to see some juicy details of Amazon's wrongdoings... and I got... a few links to other articles.
Could someone please put together some nice charts showing exactly how much Amazon is screwing everything up? I'm all for hating on Amazon but it looks pathetic when the best we can do is go "Costs are rising where Amazon is". Like... duh... but I want to see some hard evidence that proves forever exactly how bad they are.
Justifying treating others poorly just enables more people being hurt. We should not reward people for this sort of behavior. Turning a blind eye to it because "they are great software engineers" is not right.
Your comment treads very much into the "for the greater good" mentality where you can justify anything based on the results.
"Unique character trait" my ass. Obnoxious aholes are just that. Obnoxious aholes. They need to fucking stop and be more kind.
Most of the big companies treat their employees like trash and lose them rapidly. They think "Well we pay a lot so we have tons of people banging on our door to work for us, so we don't need to worry about getting new employees." This is a bad mentality.
New software engineers need to always be interviewed by those who are senior to the level at which the employee is being hired for. You will never be able to reasonably determine candidate level if you don't have more experience than they do.
The notion of "always hire employees smarter than yourself" is cute, but you don't have any way to determine rapidly that someone is.
Some recommend take home projects. I don't think those tend to work well for various reasons...
Things I do think work to find good employees:
* Give adequate time for whatever task is assigned during the interview. I nearly always see that the interview is rushed because there is inadequate time given for what is being done. If time is not available, just do a portion of the tasks and quick fail if the candidate does not pass that portion. If they succeed schedule additional interviews.
* Require open source contributions of meaning for higher level candidates. Have an interview ( an entire interview ) centered around reviewing their contributions with the candidate and discussing them.
* An interview ( 1 hr ) of the following type: Tell the candidate "Convince me why I should hire you. You have 30 minutes to present your case. I will say nothing that whole time. Afterward Q&A about what you said for 30 minutes.
* Ask questions of the candidate and don't bother with all the trickery. Bring me any software engineer and let me just ask them about random stuff freeform and I'll tell you if they suck or not within an hour. Don't demand some specific stupid process for interviewing them. You have to trust those you use to do the interview process and give them the authority to determine what the next best questions are always. The moment you turn the process into some "by the book" shit, you will get a shit process.
* If a coding test must be done, it needs to be just like on the real job in that full access is given to use websites to rapidly acquire the information needed to give the best result. Also, let candidate use their own IDE setup, and have them ready to go ahead of time. If anything, give a loose idea of what the coding task will be without details, to give the candidate time to prepare in whatever way makes sense for them to be able to tackle a task of that time.
* Give more time to accomplish tasks. So so so many of the stupid tasks I've been assigned in interviews cannot be reasonably and cleanly done within the 20-30 minutes usually given max to do them. Creating quality software takes time. Rushed software = crap software. Be real.