And specifically about removing a single SDK, not removing ad-tracking altogether (which is kind of implied from the title). Mozilla has been trying for years to monetize Firefox through ads, so I don't think people should be reading into this change too much, especially since it happened without any kind of announcement. If it were a pro-privacy decision, the marketing people would be milking this move for all they can.
- Let me save coffees I normally drink on file so I can just choose my regulars: "Temple pour over", "Starbucks Americano", etc. and it knows the ounces and mg of caffeine in that drink.
- Let me define my wake/sleep times, or like the coffees keep a few saved times to easily choose from later.
- After I drank the first coffee, it should ask me if I want another one at the optimal peak (unless it's too near to my sleep hour). Partner with DoorDash to fulfill the order.
- The important part: Because DoorDash drivers will occasionally no-show, or drink the coffee themselves, you'll need some extra cash to cover costs, comp angry customers, etc. so you'll need a Series A. So we need to convert your UI into a ChatGPT wrapper that converses with the user in a friendly way, rather than in the VB6-esque UI I see here (as slick as it is).
During their growth years when they arguably did the shadiest stuff they also had record-breaking quarterly losses in the billions while their counterpart DiDi in China was doing well enough to acquire Uber China (who according to Travis Kalanick was losing over $1b a year).
truth is Uber had no chance in China to succeed in long term regardless and Travis was naive to think CCP would let a foreign company win logistics market so rich with data.
This one seems like a blatant GPT wrapper. Why not just use 4o?
For example, "Ask any question" the use case shown is:
> "What specific python scripts are users running inside HubSpot?"
I could just ask ChatGPT that too, why would I need this product to answer the question?
Seems like everyone is just wrapping ChatGPT, creating even the identical UI down to the icon on the send button, and then making a Loom showcasing essentially white-labeled OpenAI functionality.
For future devs, what makes a product stand out (for devs) is how you built it. What's the data source? Did you fine-tune your data? Do you have people who already use it? Where does it shine? (no, a prompt isn't good enough).
Also, I don't care about Hubspot reviews when I know the product. Reviews are there for unknown software that are less popular, but even then why are you considering using some half-maintained solution for your enterprise?
I agree with you mostly but not 100%. It's definitely true that the way how you build it makes a product stand out - however the goal of this tool is more to understand WHAT to build as it gives you a glimpse into the opinions customers have about other (similar) products. The how is then onto the devs for sure.
Yes you are right if you know for instance Hubspot you do not need this application to tell you stuff about Hubspot you already know, it tells you how the audience perceives the product and the offering.
Data sources are various sites that have detailed reviews on software. We did not fine-tune anything yet as the initial goal is and was to validate the idea per se. We'll improve it further of course once we see there is a need for this.
Running Linux on a computer? I could understand your comment if the display was something very non-conventional like a series of lightbulbs instead of digital output.
It's a cool project don't get me wrong, but Nobel Peace Prize? What is this thread? I would consider something like a strandbeest to be more award-worthy - but it too is just a neat invention, not contributing to world peace or anything near it.
No, it's actually ripping out bits from an executable and turning them into relocatable object files. The technical term I've come up with for this is delinking, although the decompilation community calls it binary splitting.
Putting it another way, you can make libraries out of a program with this technique.
Anyone with the patience to read through an existing github repo can do this? If there are valuable bits to be salvaged it's easy enough to copy-paste them into a new library if you so choose.
Unless you meant copying source code from GitHub, which isn't an option if the program is a 1998 PlayStation video game and you don't have the source code for it.
It's very useful if you don't have access to the original source code.
You can do things like decompiling a program piece by piece like the Ship of Theseus. The linker will mend both original and rewritten parts together into a working executable at each step.
If you change the functionality of the rewritten parts, you have a modding framework that's far more malleable than what traditional binary patching allows.
As for quick one-shot jobs, I've created an assert extractor for a PlayStation video game by stuffing its archive code inside a Linux MIPS executable and calling into it, without figuring out the proprietary archive format or how the code inside the delinked object file actually works.
Is that meaningfully different from reverse engineering? You can't use individual functions without knowing the data structures they operate on, and info about data structures is usually not present in the final binary*.
* (excluding languages that compile to an IL like C# of course, but decompiling C# is trivial)
> You can't use individual functions without knowing the data structures they operate on, and info about data structures is usually not present in the final binary.
It turns out you can. Linkers do not care about types or data structures, all they do is lay out sections (a fancy name for arrays of bytes) inside a virtual address space and fix up relocations.
I've written case studies on my blog where I've successfully carved out whole pieces out of a program and reuse them without reverse-engineering them. I've even made a native port of a ~100 KiB Linux a.out x86 proprietary program from 1995 to Windows and all I had to do was write 50 lines of C to thunk between the glibc 1.xx-flavored object file and the MinGW runtime.
One user of my tooling managed to delink a 7 MiB executable for a 2009 commercial Windows video game in six weeks (including the time required to fix all the bugs in my alpha-quality COFF exporter and x86 analyzer), leaving out the C standard library. They then relinked it at a different base address and the new executable works so well it's functionally indistinguishable from the original one. They didn't reverse-engineer the thousands of functions or the hundreds of kilobytes of data inside that program to do so.
This is complete heresy according to conventional computer sciences, which is why you can't apply it here. I'd be happy to talk at length about it, but without literature on the topic I'm forced to explain this from basic principles every time and Hacker News isn't the place to write a whole thesis.
The question on my mind: how do you figure out what the functions do without reverse engineering?
If I were to guess, you're saying that you reverse engineer the API boundary without reverse engineering the implementation. But then figuring out what the API contact is without documentation seems intractable for most API boundaries.
For context, my tooling is a Ghidra extension, so there's all the usual Ghidra stuff that applies here.
Indeed, it depends what the API boundary is for the selection to be exported.
If it's the whole program without some well-known libraries (like the C runtime library for a statically linked executable or the Psy-Q SDK for a PlayStation video game), then the API boundary is trivial in the sense that it's a documented one. The hard part is actually figuring where those libraries are so that you can cut them out of your selection while exporting.
If it's a particular subset internal to the program then it's trickier because you don't have that (but if you know you want to export it, then you must already know something about it). Traditional reverse-engineering techniques do apply here, it's just that you only care about the ABI boundary instead of the whole implementation, so it's usually less work to figure out.
However, if you get it wrong then the toolchain will usually not detect it and you'll have some very exotic undefined behavior on your hands when you try to run your Frankensteinized program.
Troubleshooting these issues can be very tricky because my tooling doesn't generate debugging symbols, so the debugging experience is atrocious.
I've always managed to muddle through so far, but one really nasty case did take me a couple of weekends to track down (don't cut across a variable when you're exporting because you'll truncate it, which can lead among other things to corrupting whatever was laid out next in memory at runtime when the original delinked code tries to write to it).
Is code more like poetry or more like a recipe? If the former, then yes we should be allowed the time and space to craft the highest syntactic art imaginable. But if it's the latter, it should just be quick, correct, readable, and extensible.
If it's art - how dare you ruin my masterpiece?
If it's business - we had a solution deployed for the customer in less than an hour.
If syntax (poetry) is your #1 take your time. If money is your #1 you wouldn't call it "crappy code" at all. Even code that is not as performant as it could be is only "crappy" if it's affecting the bottom line (which it often does). But so-called bad code that is yielding higher profits, hard to call crappy.
It is you who starts to talk about 'art' en 'poetry' but these words do not come from what you are reacting to. One thing you seem to assume is that the 'crappy code' works and therefore the concerns about its crappiness must be about irrelevant things like 'art' or 'poetry'. However, the working of what I would consider crappy code is generally highly tenuous. There has not been found a bug, YET...., but one difference between crappy code and good code is that in crappy code one is quite sure there are lurking many bugs that are just waiting for the right circumstances to occur in practice. Also when bad code is changed, this is a much riskier affair because it is difficult to be sure that no unwanted side-effects were introduced.
There is a hypothesis that the crappy code was faster to write. At some point, this becomes false because one also has to spend time fixing the bugs. I would wager that this duration is measured in weeks, rather than months. From which it follows that the picking crappy code for speed is actually foolish and lowers profits for all but the most simple projects.
> must be about irrelevant things like 'art' or 'poetry'
If by "bad code" you mean something related to syntax, convention, or code that "might have bugs" (wtf), there is still a case it's actually "good code" if it's more readable, was a quicker solution that yields higher profits, is a less error prone approach to the larger management of the codebase albeit less performant etc.
> one difference between crappy code and good code is that in crappy code one is quite sure there are lurking many bugs
Sounds too superficial/judgmental and not evidence-based. If there is a bug there is a bug. Even perfectly written code to the best possible standard can still be code that does the wrong thing.
Poor architecture/design make code unmaintanable, or at least very expensive to maintain.
I would rather have my junior spend 3 more days to understand the FSM we use to handle our front before changing anything than him adding 2 random useState an a random useEffect because it just works.
How you handle your data is also very telling of the code quality. I'm not against the "write shit fast, fix later", it is in fact how i do my stuff, but once i have a functioning prototype and basic mocks, i then spend a long time in my models.xxx file because modeling data is like 30% of the job.
I have an example of bad data modelling: your object (that is a data representation) have fields that in certain case will be empty and you know it. Some people will ignore them. In 90% of the cases, this is a mistake that will lead to mistake down the lane. If you can use discriminated unions and don't because "it's faster" (it takes literally 2 minutes to do), you are probably writing bad code. It's not about idiomatic or not following conventions (those help) or not typing your data, it's about bad modeling choices.
> I would rather have my junior spend 3 more days to understand the FSM we use to handle our front before changing anything than him adding 2 random useState an a random useEffect because it just works.
React hooks obsoleted most use of state management tools years ago (there is even a native useReducer now so you don't have to install Redux just for that), especially if they're using SSR (Next.js) where state management has been moved to the server. There are still some cases for installing a global state management library in the FE, but usually useState / useEffect and custom hooks is enough for most React projects.
The problem is you came up with a heuristic in your mind that "global state management is pro, useState is amateur" but that isn't true.
Lets use a real example: If I worked on your team and pushed a <LoginForm /> component that captured email/pass with useState, you would tell me to move the username and password to a global state management library? Why? Dogma? It would be the wrong call.
A Login page is typically a page that if you don't use a FSM, i will make you redo your work. How do you handle MFA? Errors, including network errors since we work with offshore stations that don't have the most stable connexions? I don't see a single way using a handful of states wouldn't result in poor code. What do you do if a new oidc provider will be used? Or if we migrate to AWS and use cognito, what states should you remove, what should you add? How to you order the rendering?
Nah, if you don't want to reuse our hooks and functions that's fine, but you need a decent architecture, and using a handful of state is not it, especially not for a login page. As long as you have a process to follow in the component, not using a reducer will hurt you and the maintainability (we avoid putting business logic on the front-end to be fair, but sometimes you have no choice). And simple component that just display shit (thus don't need a reducer) aren't often given to juniors are this part of the job is uninteresting and quick to do for non-juniors. We tend to do a lot more backend and ops than front anyway.
Exactly what I meant to say, as soon as you have to add complexity, just adding useState over and over breaks, and that's what I call bad code.
It's fine if it's just a get in a component out of the way, we do not use a reducer to print our 'about' page, but typically the login is where a lot of logic has to happen.
I think I misunderstood your comment, you talked about a global manager and I thought you talked about our library.
And since we pair/mob program often enough (10 hours a week roughly, per affinity or when someone ask for help), our PR meetings are more a way to show off to the whole team a new idea or present library upgrades, but it's true that we are quite brutal, especially when i compare with my previous job where I worked with Indians and north Americans, I think it is cultural though.
> so-called bad code that is yielding higher profits, hard to call crappy
Missing the point of the person you're replying to entirely... Yes you can get higher profits with shittier code, just as you can by building shittier airplanes, cars, bridges, etc. The consequences being exploits, hacks, 737MAX, Ford Pinto, etc
I think you missed the point that it wouldn't actually be shittier code in that case.
Some ugly 4 space indented, wrong kind of loops, old Node version, mongo as the main db, no linter, callback hell SaaS platform in 1 file called "server.js" could still be more reliable and yield higher profits and sooner than your masterpiece in Rust.
No need for a dark web, Twitter and GitHub have both leaked user passwords stored in plain text on their own platforms right here on the corporate web.
Twitter who struggled to turn a profit (but not to pay its investors who became wildly rich off it) hired artists who chose technology like Ruby on Rails. They should have hired capitalists who breathed jQuery and ate pieces of sh*t like Active Record for breakfast
I have found that "it depends" is an almost universal solvent for all technical quandaries.
I have found in my experience (and I have a lot of that), that the search for "One Solution To Rule Them All" is a snipe hunt. You can't get there from here.
It always (in my experience) comes down to context[s].
That "[s]" is important. There's the current context, and then, there is the future context.
You survived your baptism in fire to live to keep delivering software.
That's great. It's crap software that got you here.
Time to rewrite it, so we now have software with a future
Right?
OK?
That's what we'll do...right?
Oh, for Cthulhu's sake, what do you mean we need to keep building on our foundation of sand?
Congratulations. You now not only have technical debt; you have technical bankruptcy, coming down the road.
Better sell the company fast, before the bomb goes off...
The mythical "later" never happens. Today we need to get version 1.0 to the market ASAP. Tomorrow we will need to get version 2.0 to the market ASAP. Etc.
It's like people who promise that they will stop smoking later. Twenty years later, they usually still smoke. Twenty years later, if the software still exists, all the technical debt tickets will probably still be in the backlog.
> If it's business - we had a solution deployed for the customer in less than an hour.
Boeing was good at finding cheaper solutions to business problems as well. In the end it's society that suffers for our tolerance of late stage capitalism.
There is no "right" answer to this. But tolerating crappy engineering because it's cost effective seems like an admission of defeat to people that actually want to make things better. It's not so much letting perfect be the enemy of good enough; it's more about the steady decline in quality because that's what we incentivize.
Desktop users interested in a privacy-first Firefox should try Waterfox https://www.waterfox.net/