What people often don't realize is that in a big business system a user may have no permission to raw data of some table, but may have permission to report which includes aggregated data of the same table, so report permissions cannot be deducted from base CRUD permissions.
If such SIAAS
- Checks that query is SELECT query (can be tricky with CTE, requires proper SQL parser)
- Allows editing said query by superuser only
- Can be parametrized, including implicit $current_user_id$ parameter
- Has it's own permissions and users can run the query if they have permissions
It's safe enough. I've seen and applied such "Edit raw SQL in HTML form" many times. It's super flexible, especially combined with some CSV-to-HTML, CSV-to-PDF, or CSV-to-XLS rendering engine.
Former Head of Security GRC at Meta FinTech, and ex-CISO at Motorola. Now, Technical Founder at a compliance remediation engineering startup.
Some minor nits. One can't be SOC 2 "certified". You can only receive an attestation that the controls are designed (for the Type 1) and operating effectively (for the Type 2). So, the correct phrase would be that Excalidraw+ has received its "SOC 2 Type 1 attestation" for the x,y,z Trust Services Criteria (usually Security, Availability, and Confidentiality. Companies rarely select the other two - Privacy, and Processing Integrity - unless there's overlap with other compliance frameworks like HIPAA, etc.)Reason this is important is because phrasing matters, and the incorrect wording indicates lack of maturity.
Also, as others have said, no one "fails" a SOC 2 audit. You can only get one of four auditor opinions - Unmodified, Qualified, Adverse, and Disclaimer (you want to shoot for Unmodified).
As fyi, the technical areas that auditors highly scrutinize are access management (human and service accounts), change management (supply chain security and artifact security), and threat and vulnerability management (includes patch management, incident response, etc). Hope this information helps someone as they get ready for their SOC 2 attestation :-)
Similarly, the report areas you want to be very careful about are Section 3: System Description (make sure you don't take on compliance jeopardy by signing up for an overly broad system scope), and Section 4: Testing Matrices (push back on controls that don't apply to you, or the audit test plan doesn't make sense - auditors are still stuck in the early 00's / "client server legacy data center" mode and don't really understand modern cloud environments).
Finally, if you're using Vanta/Drata or something similar - please take time to read the security policy templates and don't accept it blindly for your organization - because once you do, then it gets set in stone and that's what you are audited against (example - most modern operating systems have anti-malware built in, you don't need to waste money for purchasing a separate software, at least for year one - so make sure your policy doesn't say you have a separate end point protection solution running. Another one, if you have an office that you're using as a WeWork co-working space model only, most of the physical security controls like cameras, badge systems etc either don't apply or are the landlord's responsibility, so out of scope for you).
Hope this comment helps someone! SOC 2 is made out to be way more complicated (and expensive) than it actually needs to be.
In most scenarios, you are no longer running with multiple users on the same machine.
Either this is a server, which has an admin team, or a client machine, which _usually_ have a single user.
That isn't 100% true, and local privilege escalation matters, but it is a far cry from remote code execution or remote privilege escalation.
Note about GitHub Windows Actions runners: I think I understand what is wrong with them, though it's somewhat conjecture since I don't actually know how it works internally.
It looks like the free CI runners have C: drive pointing to a disk that is restored from a snapshot, but often times it hasn't finished restoring the entire snapshot by the time your workflow runs, so IO can be very slow, even if you don't need to read from the still-frozen parts of the disk. Some software ran inside workflows will do heavy R/W on C: drive, but it's better to move anything that will be written to disk, e.g. caches, to D: if possible. This often leads to much better performance with I/O and more predictable runtimes, particularly when there isn't a lot of actual compute to do.
The fact that so few people blog these days makes blogging even more influential than it used to be.
You can establish yourself as something of a global expert on some topic just by writing about it a few times a month over the course of a year!
Don't expect people to come to your blog. Practice https://indieweb.org/POSSE - Publish (on your) Own Site, Syndicate Elsewhere - post things on your blog and then tweet/toot/linkedin/submit-to-hacker-news/share-in-discord etc.
Also, don't worry too much about whether you get traffic at the time you write something. A lot of the reputational value comes from having written something that you can link people to in the future. "Here are my notes about that topic from last year: LINK" - that kind of thing.
There's a lot to be said for writing for its own sake, too. Just writing about a topic forces you to double-check your understanding and do a little bit more research. It's a fantastic way of learning more about the world even if nobody else ever reads it.
First you have to make space in your life for it. You need long blocks of time for deep work.
The first idea you pick is unlikely to work, so pick something and start moving. Many of the best products come out of working on something else.
When building, optimize for speed. Try to get something out in the world as quickly as possible and iterate from there.
Pick a tech stack you're familiar with, that you'll be fastest in.
Try to spend half your time on marketing/sales, even if you hate it.
The most important skill you can have is resiliance. Not giving up is the best path to success. This is hard because there is so much uncertainty in this career path.
It's worth it! The autonomy and freedom are unmatched by any other career.
I’ve often said that it is the speed of deployment that matters. If it takes you 50 minutes to deploy, it takes you 50 minutes to fix a problem. If it takes you 50 seconds to deploy, it takes you 50 seconds to fix a problem.
Of course all kinds of things are rolled up in that speed to deploy, but almost all of them are good.
This is called prototyping, which is a valuable part of the design process; some people call it "pathfinding".
These are all inputs into the design. But a design is still needed, of the appropriate size, otherwise you're just making things up as you go. You need to define the problem your are solving and what that solution is. Sometimes that's a 1-page doc without a formal review, sometimes it's many more pages with weeks of reviews and iterations with feedback.
Don't forget: "weeks of coding can save hours of planning" ;)
Whenever you're called on to make up your mind, and you're hampered by not having any, the best way to solve the dilemma, you'll find, is simply by spinning a penny.
No—not so that chance shall decide the affair while you're passively standing there moping; but the moment the penny is up in the air, you suddenly know what you're hoping.
- Download as many LLM models and the latest version of Ollama.app and all its dependencies.
- Make a list of my favorite music artists and torrent every album I can.
- Open my podcast app and download every starred episode (I have a ton of those that I listen to repeatedly).
- Torrent and libgen every tech book I value. Then, grab large collections of fiction EPUBs.
- Download every US Army field manual I can get my hands on, especially the Special Operations Medic manual, which is gold for civilian use in tough times.
- Download every radio frequency list I can for my area of the country.
- Download digital copies of The Encyclopedia of Country Living by Carla Emory, Where There Is No Doctor, and Where There Us No Dentist.
I already have paper versions of almost all of these but it’s handy to have easily-reproducible and far more portable digital copies.
It really depends on how mature your org and stacks are. This is generally how I would do it.
1-20 people - password manager (bitwarden, 1pass, etc.)
20-30+ people - SSO
50+ people - start assigning real roles to your SSO schema
1-5 services - secrets in CircleCI and password manager is good enough.
5+ instances - use a secrets manager like Vault.
10+ instances - start using a secrets manager locally as well for dev. Start to consider using well scoped IAM policies for each of your services and team members.
15+ instances - start to think about adding additional zero trust boundaries.
Of course, this is very rough. Depending on your regulatory/compliance requirements and how much revenue you’re bringing in and from who, you might have to do this stuff sooner. In general, it should go:
1. Centralize secrets even if you can’t easily revoke people (password manager).
2. Make things easily revocable and centralized (sso).
3. Make roles and access finer grain (RBAC).
4. ^ with automation between all of these steps where it makes sense.
Something I would warn anyone of is building your own auth/secrets core tooling. This stuff is incredibly complex because of the edge cases and it’s just not worth the risk you take on by saving money unless you have a really good core business reason to roll your own. It’s also dangerous to prematurely optimize and pay the SSO tax too early. You will find that a lot of engineers appeal to emotion when it comes to risk. Something extremely helpful is going through and actually assigning a security risk score for all your systems. This might be tedious, but it brings a lot of clarity to the conversation of “what do we want to build when? What risk can we take on at any given stage?”
In essence we have defined within each domain:
a) Public folder with code that other domains can use
b) domain folders (src and infra) with code that only given domain can use. This way developers know not to change public contracts for a (or if they do change them they do understand they're changing public code) be it method signatures or interfaces and are free to refactor b, because these classes should not be publicly accessible and can change at any time. Even extending classes defined this way is disallowed.
This becomes helpful when operating within confines of monolith application, but with different teams owning different parts of the application. Trying to use non-public part of each domain will be prevented on commit level (developers will not be able to commit their work) rather than run level though
It's similar to Dokku but has a nice web UI, makes it easier to deploy Docker/Compose solutions and auto LetsEncrypt functionality is built-in by design (not as a separate plugin).
I read this book called "How Big Things Get Done." I've seen my fair share of projects going haywire and I wanted to understand if we could do better.
The book identifies uniqueness bias as an important reason for why most big projects overrun. (*) In short, this bias leads planners to view their projects as unique, thereby disregarding valuable lessons from previous similar projects.
(*) The book compiles 16,000 big projects across different domains. 99.5% of those projects overrun their timeline or budget. Others reasons for slipping include optimism bias, not relying on the right anchor, and strategic misrepresentation.
For runtime cost analysis, you could try Steampipe [1] with it's Powerpipe "thrifty" [2] mods. They run dozens of automatic checks across cloud providers for waste and cost saving opportunities.
If you want to automatically make these changes (with optional approval in Slack) you can use the Flowpipe thrifty mods, e.g. AWS [3].
It's all open source and easy to update / extend (SQL, HCL).
Does WezTerm support an equivalent of iTerm's "hotkey window"?
For those unfamiliar, that's a window tied to a show/hide keybinding which when shown floats above all other windows, making a terminal instantly available everywhere - a feature I could live without, but don't care to. I'd love to switch for all of WezTerm's other features, but without that it's simply a nonstarter for me.
using zalando's patroni operator in k8s at scale for years (mainly OCP but pure k8s as well).
Features like in place major version upgrade are no match for any of the alternatives checked.
Close to it is CNPG (cloudnative-pg) which is 2nd best and in 1yr might take the crown.
(for companies, best part is that cnpg has enterprise support for it (named pg4k, a fork of cnpg).
But, above all, I would warmly recommed anyone to first do their best to use cockroachDB (or yugadb if you like more) instead.
The benefits of distributed/horiz scaled DB usually overcome the effort of moving to it (which should not be big as it's using same pg client/protocol). And it's free if you don't need enterprise features like partitions, etc.
> Axiom 2: You’re optimizing over a business, not over a codebase.
Well said. Ultimately I think this is where much of the communication breakdown occurs when discussing Framework A vs Framework B online.
If you’re optimizing for _code_, sure. Stress about the ms it takes to load this or that thing. Client vs server. All of it is valid discussion from an engineering standpoint. Go nuts!
If you’re optimizing for _business_, then choose something that gets the job done. Fewer moving parts - and fewer resources needed to maintain it - the better.
This is wild. I've spent the last three weeks working on this stuff for two separate clients.
Important note if you're taking advice: cache-from and cache-to both accept multiple values. Cache to just ouputs the cache data to all the ones specified. cache-from looks for cache hits in the sources in-order. You can do some clever stuff to maximize cache hits with the least amount of downloading using the right combination.
If you ever happen to study computer science, you may come across a subject called "coding theory". It introduces you to compression as well as many other topics such as error correction (Reed-Solomon, used in RAID5, RAID6 and ECC-RAM), line coding (sometimes you need to flip bits to keep the clock on both sides in sync, no clock-signal for a long time may cause clock loss) and a lot of wonderful but weird stuff.
Let us go into detail on compression:
There is a representation. US-ASCII uses 8 bits per latin letter, UTF-32 uses 4 bits per latin letter. It is just a temporal representation to the machine -- usually in memory only, it does have the same amount of information, you can save it more efficiently to disk. You would not want to save either format to disk, it is a waste of space.
Information content (I hope my translation is correct, scan Wikipedia for details) cannot be compressed. But it can be calculated. The more seldom a letter, the more information its occurence carries. As soon as each letter is not equally frequent (compare space and "q") the information density drops.
Calculation is quite simple: Count the occurence of each letter, count the caracters used (if there is no "q" in the text, you got to save one letter and its encoding) and apply some math
For some easy examples, think of morse code and Huffman coding -- not every letter needs to be encoded using the same amount of bits.
> How much data can lowercase save? #
Nothing. Either there is (almost) no information to it in the first place, in that case compression will take care of it for you. There could only be information to it if uppercase letters were equally likely as lowercase letters
> How much data can lowercase save? #
Why do you even stop at letters? You could build a dictionary of words and compress references to it. The compression efficiancy would only depend on the amount of words, regardless of case and regardless of character set. That is why entropy depends on "symbols" instead of "letters"
So the biggest problem is to actually render your cv. For this I use https://ohmycv.app. Its a nice (free) editor, and you can write CSS for the styling, works great. I source control the markdown and CSS, i have multiple versions of the same CV, so I can change content while keeping the format the same.
I really appreciate what this project is going for. SQLite with practical replication gets to be pretty dangerous for other vendors in the space. It's the last thing we really needed for our end game customers.
Unfortunately, our org is being pushed away from SQLite because our domain is highly regulated. We have a really hard time getting something like this through technical review, especially for our up-market clients. The only thing I could defend is if this was somehow part of the first party solution and code base.
I can sell SQLite to a bank if they are tolerant to single node failure semantics (I.e. vm snapshot restore). That part is no problem. Already did it half a dozen times myself. It gets tricky if they want more aggressive RPO. I cannot sell log-replicated SQLite if it relies on another, lesser-known 3rd party for that capability. I can get away with murder on my front end vendors but data vendors never seem to escape scrutiny.
I want to hate SQL Server, but it's starting to grow on me. The knowledge that I won't have to argue with a hundred+ CTO/CIOs is starting to win out over the principled nerd things.
Replicating SQLite feels like a cursed thing for many contexts - If someone isn't happy with periodic snapshots, then the nature of their business is probably pretty serious and they probably want deeper (perhaps legal) guarantees about how things would go.
If anyone wants to finetune their own Mistral 7b model 2.2x faster and use 62% less memory - give our open source package Unsloth a try! https://github.com/unslothai/unsloth thanks! :)
It seems like the author agrees with you and picked a confusing title for the article. The article ends with a set of equations:
user > ops > dev
biz > ops > dev
biz ≹ user
The conclusion seems to be that code exists in service to the end-user and the business. The last equation (≹) is a neat way of describing that both end-user and the business are equally important to the existence of the code, even though their needs aren’t the same.
If such SIAAS
It's safe enough. I've seen and applied such "Edit raw SQL in HTML form" many times. It's super flexible, especially combined with some CSV-to-HTML, CSV-to-PDF, or CSV-to-XLS rendering engine.