This is not true. Both OpenAI and Google's LLM APIs have a policy of not using the data sent over them. Its no different than trusting Microsoft's or Google's cloud to store private data.
Can you link to documentation for Google's LLMs? I searched long and hard when Gemma 2 came out, and all of the LLM offerings seemed specifically exempted. I'd love to know if that has changed.
Thanks very much! I think before I looked at docs for Google AI Studio, but also for Google Workspace, and both made no guarantees.
From the linked document, so save someone else a click:
> The terms in this "Paid Services" section apply solely to your use of paid Services ("Paid Services"), as opposed to any Services that are offered free of charge like direct interactions with Google AI Studio or unpaid quota in Gemini API ("Unpaid Services").
Enterprise features like Gemini for Workspace (generative AI features in the office suite), Gemini for Google Cloud (generative AI features in GCP), Gemini Code Assist, Gemini in BigQuery/SecOps/etc do not use data for training.
The Aider leaderboards seem like a good practical test of coding usefulness: https://aider.chat/docs/leaderboards/. I haven't tried Cursor personally but I am finding Aider with Sonnet more useful that Github Copilot and its nice to be able to pick any model API. Eventually even a local model may be viable. This new Gemini model does not rank very high unfortunately.
Thanks for the link. That's unfortunate, though perhaps the benchmarks will be updated after this latest Gemini release. Cursor with Sonnet is great, I'll have to give Aider a try as well.
It's on the leaderboard, it's tied with qwen 2.5 72b and far below SOTA of o1, claude sonnet, and deepseek. (also below very old models like gpt-4-0314 lol)
I dislike how Jupyter notebooks have become normalized. Yes, the interactive execution and visuals are nice for more academic workflows where the priority is quick results over code organization. However, when it comes to sharing code with others for the sake of doing reproducible science, jupyter notebooks cause more trouble than they are worth. Using cell based execution with python is so elegant with '# %%' lines in regular .py files (though it requires using VSCode or fiddling with vim plugins which not all scientists want to do I suppose). No .ipynb is necessary, .py files can be version controlled and shared like normal code while sill retaining the ability to use interactively, cell by cell.
Its much easier to organize .py files into a proper python module, and then share and collaborate with others. Instead, groups will collect jumbles of slightly different versions of the same jupyter notebooks that progressively become more complex and less manageable over time. It's not a hypothetical unfortunately, I've seen this happen at major university labs. I'm not blaming anyone because I understand -- the funding is there to do science and not rewrite code to build convenient software libraries. Yet, I can't help but wish jupyter notebooks could be removed from academic workflows.
I think there's a fundamental mistunderstanding and mismatch between what you want to do, and what Jupyter notebooks are for. The distinction is between code versus the results.
If the code is the end product, sure, use a python package.
But does your .py with `# %%` in it also store the outputs? If not, why even bring this up? A .py output without the plots tied to the code doesn't meet the basic use case.
If the end product is the plot, I want to see how that plot was generated. And a Jupyter notebook is a much much better artifact than a Python package, unless that Python package hard codes the inputs and execution path like a notebook would.
Over the past 20 years of my career I have run into this divergence of use cases a lot. Software engineers seem to not understand the end goals, how it should be performed, and the learnings of the practitioners that have been generating results for a long time. It's hard to protect data scientists from these inflexible software engineers that see "aha that's code, I know this!" without bothering to understand the actual use case at hand.
Not having the outputs tied into the code is actually preferable if the ultimate goal is reproducible science. Code should be code, documentation should be documentation, and outputs should be outputs. Having multiple copies of important code in non-version controlled files is not a good practice. Having documentation dispersed with questionable organization in unsearchable files is not good a practice. Having outputs without run information and timestamps is not a good practice. Its easy to fall in to those traps with Jupyter notebooks. It might speed up initial set up and experimentation, but I've been working academic labs long enough to see the downstream effects.
Yeah, jupyter notebooks don't guarantee any specifics about versions of code used for that output. In the real world you can expect everyone in the lab including all of the students to be editing jupyter notebooks at whim. The only way to do this would be to have proper version control and of your code, a snapshot of the environment, and to log all this along with the run that generated the output. This is possible with regular python using git, proper log files, etc. Jupyter notebooks seem like an extra roadblock.
Ooh. That's a nice utility funtion that I will write soon. We tend to look at requirements as something we hope the package manager gets right, and then we ignore at runtime, but there are a bunch of errors we could avoid if we verified at runtime. Sometimes when writing a library you have to have different code paths for different versions.
Something like
`if check_versions(pandas__gt="2.0.0", pandas__lt="3.0.0"):`
Often the notebook was run on a beefy server with GPUs attached, potentially taking hours/days of compute. It would be senseless to force every viewer of a Jupyter notebook to have the same setup and time just to read through the results and output.
> Not having the outputs tied into the code is actually preferable if the ultimate goal is reproducible science.
What a strange thing to assert, especially as a general overarching truth.
The best reports I have ever seen have matched code and output in the same file. There's never a question of what code generated a plot or a table with a notebook.
With .py files and separate outputs there's far more change for unreproducibke science, it's far messier, and for someone who doesn't appear to respect the organizational capabilities of academic labs, you are condemning them to far more poorly organized outputs.
> Having multiple copies of code
That doesn't have anything to do with notebooks. It's as silly as saying that a Python package is a poor idea because you say somebody repeat code across multiple places.
> non-version controlled files
Notebooks are no less version controllable than .py files.
> outputs with timestamps and run information
Jupyter notebooks are perfect for this, far superior to a directory of cryptically named outputs that need to be strung together in some order
> documentation dispersed with questionable organization
Using separate Python files rather than a notebook means that documentation can never be where it needs to be: next to the output. This is one of the ways that Python files are strictly inferior for generating results.
There are roughly two modes for notebooks: exploration with a REPL, and well-documented reports. The best scientific reports I have ever seen are notebooks (or R Markdown output) that are the full report text plus code plus figures.
> someone who doesn't appear to respect the organizational capabilities of academic labs, you are condemning them to far more poorly organized outputs.
This is not a great way to make your argument, though you are not the not only one here making a personal judgement without even knowing about my background. These are all issues I have seen first hard. With most academic labs being funding limited, the "organizational capabilities of academic labs" seems irrelevant to me. In our field, no one is getting grants to manage code of any kind .py or .ipynb and I suspect its the same at most university labs. It's effort wasted that ultimately does take time away from the actual research that's fundable and publishable. As someone who has been responsible for wrangling people's notebooks in the past, it's enough of a problem that I would encourage to remove all .ipynb.
> That doesn't have anything to do with notebooks. It's as silly as saying that a Python package is a poor idea because you say somebody repeat code across multiple places.
Human factors make jupyter notebooks lead to the problems I have listed. The issues are most apparent with large groups and over long periods of time. Python and other programming languages already solved most of these problems with git. There isn't a tool that is as elegant and scales from individuals to massive organizations.
> There are roughly two modes for notebooks: exploration with a REPL, and well-documented reports. The best scientific reports I have ever seen are notebooks (or R Markdown output) that are the full report text plus code plus figures.
The REPL functionality is handled by .py cell execution, as I’ve mentioned in other comments. It baffles me how the minimal effort saved by not using separate tools -- one for code, one for documentation -- justifies the issues it introduces.
I use jupyter notebooks at work, not so much for academic stuff, but often to help build and show a narrative to folks, including executives (where I have any even remotely technical leadership). It's great for narrative stuff, especially being able to emit PDFs and what not. I've been in a number of meetings where I've got the code up in Jupyter, sharing the screen, and leadership want us to tweak numbers and see the consequences.
It's great for exploring code and data too, especially situations where I'm really trying to feel my way towards a solution. I get to merrily intermingle rich text narrative and code so I explain how I got to where I got to and can walk people through it (I did that with some experimenting with an SMT solver several months ago, meant that people that had no experience with an SMT solver could understand the model I built).
I'd never use it to share code though. If we get to that stage, it's time to export from jupyter (which it natively supports), and then tidy up the code and productionise it. There's no way jupyter should be the deployed thing.
That seems like a reasonable way to use jupyter notebooks since you have an actual plan to move beyond it when necessary. My issue is mostly with the way its misused, often by people who are arguably at the top of the field.
We've seen how this ends because mathematicians have been sharing Mathematica notebooks forever. It's not pretty.
Like you I see the appeal, but they're a usability nightmare beyond a few lines. Part of the problem, I think, is that you can't really incrementally improve them. Who wants to refactor a notebook and deal with all the cell dependency breakage?
So they start off okay and then slowly become terrible until they're either irreplaceable or too terrible to work with and a new one is started.
The same problem exists with spreadsheets. Should we get rid of excel (the single tool that literally runs half the world), and start manually writing markdown tables in text files?
The tool and the tool maker are supposed to serve the user. The user is not supposed to conform to the whims of the tool maker.
Since 94% of business spreadsheets contain errors [0], then probably yes we should get rid of or significantly improve spreadsheets.
Probably the solution is that things like Jupyter notebooks and spreadsheets should be views into some better source of truth rather than the source of truth themselves.
Suppose you have some formula that computes a financial metric for your company. Someone you've shared it with drunkenly fat-fingers the formula 3/4 of the way down a long row, and that causes all entries below it to recompute with the wrong formula. Unless the change is really drastic, you may never know it happened.
And this sort of mistake -- basically a typo or a bad mouse movement -- happens daily in every company in the world in some spreadsheet. Often people will notice the mistake, but not with probability 1.
Software engineers have mechanisms to guard against some of these mistakes, and even we have a hard time getting people to take code review or tests seriously. What is the guard in the spreadsheet world?
Another issue is that jupyter, pandas, and polars don't take displaying tabular data seriously. Just have a better default table display widget. Look at ipydatagrid, perspective, or buckaroo (my project) for examples of how it could be done better.
I don’t disagree anything you said. Jupytext can be a good tool to bridge some gap, where you pair ipynb to a py script and can then commit the py only (git-ignore all ipynb for your collaborators.)
Also, while many practices out there is questionable, in alternative scenarios where ipynb doesn’t exist, they might have been using something like matlab for example. Eg, in my field (physics), often time there are experimentalists doing some coding. Ipynb can be very enabling for them.
I think a piece of research should be broken down and worked by multiple people to improve the state of the project. Some scientists might be passing you the initial prototype in the form of a notebook, and some others should be refactoring to something more suitable for deployment and archival purpose. Properly funding these roles is important, and is lacking but improving (eg hiring RSE.)
In my field, the most prominent way when ipynb is shared a lot is for training. It’s a great application as that becomes literate programming. In this sense notebook is highly underused as literate programming still hasn’t got mainstream.
I've looked into Jupytext, but ultimately decided to go with pure python. Most of the practical functionality can be replicated, but I do admit there isn't a easy single install tool or guide to replace notebooks at the moment.
I think the notebooks are a fine learning tool to introduce people to programming initially, but I'm afraid it doesn't allow for growth beyond a certain level. You have a good point about funding for those software roles. Perhaps this may not be as big of a concern if there were more software talent in these labs to handle the issues that arise.
In an ideal world that we control everything and/or don’t need to collaborate with others, then whatever tooling one use is actually not that important (and each can choose the best fitting their needs.) So Jupyter+Jupytext is useful in the context of collaboration, where you can’t control your collaborators but want something from them.
While in an ideal world scientists who write softwares should write professionally, the same goes for anything they do, including math and stats used in their research, writing and typesetting and generates publishing quality visualization… That rarely happens because of how the academic world is financed, and the incentives associated with it. I can certainly complain about that all days, but in short a researcher hired by a research university, especially with a tenured track position in the US, will not be successful to get such position, let alone getting tenured, if they had not focused their scarce resource of time to maximize their “research output” (publications, grant, etc.), where software engineering is not part of. (Sorry, sentence too complicated.)
In the end, usability wins. In a Jupyter notebook, you have a much better idea of state between cells, you can iterate much faster, you can write documentation in readable markdown. Often, Jupiter notebooks are more like interactive markdown than they are like python scripts.
The form factor of Jupyter notebooks seems to fit well with peoples workflows though. Looks like you just wish the internals of Jupyter were better architected.
Imo, the better architected .ipynb is simply .py with '# %%' blocks. It does almost everything a .ipynb can do with the right VSCode extensions. Even interactive visualizations can be sent to a browser window or saved to disk with plotly. Though I do wish '# %%' cell based execution was accessible to more people.
There isn't a single install tool that "just works" for this at the moment. If editors came with more robust support for it by default, I think the notebook format wouldn't be needed at that point and people could use regular python and interactive cell based python more interchangeably. I've seen important code get buried under collections of jupyter notebooks across different users so I have a good reason for this. Notebooks simply dont scale beyond a certain complexity.
The two can coexist. store libraries in python code that is versioned and deployed properly. Notebooks with their data ingest, code, then output should read cleanly. Making the ingest and code readable is the job of library writers. A clean and elegantly coded notebook with inline outputs is a substantively different experience than searching all over the place for the correct browser window that corresponds to the output from a given piece of code.
Mojo claims to be interoptable with python, but it seems only one way. There's no built in way to use the binaries and use them with a regular python environment. It would be hard to incrementally migrate from an existing project. Something like Cython would allow this. Couldn't the GPU features be accessed from C/Cython instead? Migrating a whole project to Mojo would require more time investment and I am not even sure if all the dependencies would be compatible.
Its certainly not altruism. Given that Facebook/Meta owns the largest user data collection systems, any advancement in AI ultimately strengthens their business model (which is still mostly collecting private user data, amassing large user datasets, and selling targeting ads).
There is a demo video that shows a user wearing a Quest VR headset and asks the AI "what do you see" and it interprets everything around it. Then, "what goes well with these shorts"... You can see where this is going. Wearing headsets with AIs monitoring everything the users see and collecting even more data is becoming normalized. Imagine the private data harvesting capabilities of the internet but anywhere in the physical world. People need not even choose to wear a Meta headset, simply passing a user with a Meta headset in public will be enough to have private data collected. This will be the inevitable result of vision models improvements integrated into mobile VR/AR headsets.
That sounds fantastic. If they make the Meta headset easy to wear and somewhat fashionable (closer to eyeglass than to a motorcycle helmet), I'd take it everywhere and record everything. Give me a retrospective search and conferences/meetings will be so much easier (I am terrible with names).
I wouldn’t even say hi alone my name to someone wearing a Meta headset out in public. And if facial recognition becomes that common for wearers, most of the population is going to adorn something to prevent that. And if it’s at work, I’m not working there and I have to think many would agree. Coworkers don’t and wouldn’t tolerate coworkers taking videos or pictures of them.
This is not how the overwhelming majority of the world works though.
> if facial recognition becomes that common for wearers, most of the population is going to adorn something to prevent that
"Most of the population" is going to be "the wearers".
> Coworkers don’t and wouldn’t tolerate coworkers taking videos or pictures of them.
Here is a fun experience you can try: just hit "record" on every single Teams or Meet meeting you're ever on (or just set recording as the default setting in the app).
See how many coworkers comment on it, let alone protest.
I can tell you from experience (of having been in thousands of hours of recorded meetings in the last 3 years) that the answer is zero.
You are probably right, but that is truly a cyberpunk dystopian situation. A few megacorps will catalog every human interaction and there will be no way to opt out.
Of course, no Hacker News thread is complete without the "I would never shake hands with an Android user" guy who just has to virtue signal.
> And if facial recognition becomes that common for wearers, most of the population is going to adorn something to prevent that
My brother in Christ, you sincerely underestimate how much "most of the population" gives a shit. Most people are being tracked by Google Maps or FindMy, are triangulated with cell towers that know their exact coordinates, and willingly use social media that profiles them individually. The population doesn't even try in the slightest to resist any of it.
I think one of the big problems with VR (and also AR) is that the large companies lack focus and have been trying to make generic do-everything devices to cover many applications. It may make sense from a business point of view since it would ensure the largest user base. However for such a new technology that has a wide variety of potential applications, this means that no one application is given the resources and attention it really needs. Hardware upgrades have negligible impact, software and ux design is not focused on a specific need, and many fundamental issues are left unsolved.
VR companies are trying to make the iPhone of VR without considering that the iPhones success was built on decades of computing fundamentals. Before its possible to make good hardware and XR experiences, we'll need basic research in optics, display panels, tracking, multiview eye tracked foveated rendering, gaze correction, vari-focal, lossless wireless... the list can go on and on. Very few want to invest in solving these problems and simply wants to build a huge ecosystem with a large user base. Even Facebook/Meta, who have invested the most, have failed to tackle any of the major problems even after 10 years of being in the field. Since 2016 when 6-DoF tracked controllers became the norm, there hasn't been any major advancements other than slightly better visuals.
Looking at XR technology that has been successful, its usually because of a very clear focus on a specific application. VR flight and racing simulations with professional headsets like the Varjo appear seem far more developed. With a motion rig, these are good enough for training professionals. VR has solidified its place its this niche market at least. Microsoft's success often gets overlooked, but they have a $20B defense contract to supply IVAS AR headsets to the US military. If more companies focused on solving one of fundamental problems, it should eventually be possible to create a mainstream mass-market device that everyone will want to use.
Well, the wireless part is already pretty much here. With a good Wifi 6E or 7 router, Virtual Desktop (https://www.vrdesktop.net) is good enough that you're limited by your GPU power more than anything else.
There's several problems with that. 1. The latency - even if fine for slower games its enough to cause slight vestibular-ocular mismatch and discomfort. 2. Compression and visual quality - not only is the quality worse but its also cost using more GPU resources for the lower quality compared to a DisplayPort signal. 3. the Wifi 6E RF bands and protocols are not suited for lossless, low latency video transmission. Especially as we approach 4K per eye resolutions, the bandwidth is not there and relying on additional encode/decode hardware adds more latency and artifacts. We also need a solution that would allow for multiple users in a single building to use wireless VR, which I don't believe will be possible with the RF bands available.
There was new Wigig standard that may have solved this, but I believe its not being used anywhere.
I am aware people use it, but its only a partial solution that introduces new issues. For certain users it may be sufficient but even if you ignore the latency and compression issues, being unable to have multiple headsets adjacent makes it an incomplete solution if the goal is spreading the technology to new users. Even multiple WAPs won't get around the bandwidth congestion.
This is what I do essentially. I make a new conda env for each project and use pip or conda install. What if I have a new project that needs components from two projects? Sometimes there will be impossible to solve dependencies when trying to use both components. Its not feasible to dive into each dependency within each dependency to figure out how to resolve them.
Rust's package manager, cargo, is able to handle this by allowing multiple versions of libraries to be installed in a single environment. Why can't python do that? How can one solve this with conda/pip or any currently available python tool? I've given up and decided to use websockets between different python processes from different environments.
Is this not a problem given impeachment votes will follow party lines? A party with the presidency and with >1/3 of the senate would have unchecked power. As long as there are individuals who are willing to execute the orders (who can later be pardoned), the president could delay elections or eliminate political rivals indefinitely. The system of checks and balances were put in place by the founders assuming each party will serve their own interests. Politics aside, if this immunity is given to the president, the current system would provide no checks for the executive branch of a party willing to exercise the full extent of those powers. People would essentially be expecting on good faith each election that the president will not become a dictator; there would be no procedure to actually prevent that.
My concern is the immunity allows for perpetual, single party rule with only a 1/3 of senate seats and the presidency. There would be no checks in place at the federal level if the party was willing to exercise power to interfere with elections or opposing candidates.
If its for training a new foundation model it is not that bad. It's still only a fraction of the energy compared to many human industries. I did rough math some time ago and found that that training llama-3-70B used the equivalent energy to 1/30 of a full loaded container ship going from China to the US. Even scaled up 100x and trained 10x longer, its seems like the energy consumption is relatively small compared to other industries. The fact that people are considering nuclear power for AI training is an advantage not a downside, imo. It should have a much lower CO2 footprint.
Yes, and consider that with the current hype around AI and enough (venture) capital there will be several corporations competing for the best AI and suddenly we are at several "nuclear plants" or equivalent energy "consumption".
I don't see increasing demand for nuclear power as a disadvantage. We have nuclear material that can last humanity 1000s of years at least. The CO2 footprint is an issue but nuclear is much better than others. Personally, I think it's better we utilize more energy and discover new breakthroughs while society is relatively stable and functioning, because there's no guarantee that it will last. Population collapse seems imminent in more educated societies, even China and India are trending this way now. Without some level of AI assistance, humanity would likely lose a great deal of productive output.
Also, if this path to AGI does not work out, its not as though the nuclear reactors will be wasted. People will find something else to do with the energy.
Sure I agree, but if we compared value it generates per unit energy it would still probably be better than many non-essential industries: the entertainment industry, fashion industry, alcohol, etc. Even in the current state LLMs can provide more useful practical value compared to industries with higher energy and CO2 footprints.
