Frontend Feeds

Category

The Giants

6 Sources

  • DEV CommunityThe Giantsread at source

    OpenAI doubles Pro limits and merges ChatGPT and Codex usage

    OpenAI has announced changes to how ChatGPT and Codex usage works, according to BleepingComputer. The reporting is brief, so this article covers only what is confirmed and points out what is still unknown. What happened BleepingComputer reports that OpenAI has confirmed three changes: Usage limits for the Pro plan are being doubled. ChatGPT Work capabilities are being rolled out directly into regular Chat. Usage allowances across ChatGPT and Codex are being combined. The sources do not say which plans beyond Pro are affected, what the old and new limits are in concrete numbers, how the combined allowance is calculated, or when the rollout reaches all users. Those details should come from OpenAI's own announcement. Why it matters For engineers who use ChatGPT for planning, debugging or research and Codex for coding tasks, usage limits shape how you work. Running into a cap mid-task is disruptive. A combined allowance for ChatGPT and Codex suggests that usage in both products may come from a shared pool. That is an inference from the reporting, not a confirmed detail. If it holds, heavy use of one could leave less for the other, so it's worth watching how consumption is displayed in your account. Bringing Work capabilities into regular Chat may also simplify things by reducing the need to switch between separate experiences. What the Work features include is not described in the sources, so evaluate them directly before relying on them. The doubled Pro limits are good news for heavy users on paper. Without the baseline numbers, the practical effect is hard to judge. What you should do Read OpenAI's official announcement for the exact limits, the plans covered and the rollout schedule. If you're on Pro, watch your usage over the next few weeks to see how the new limits feel in practice. If you use both ChatGPT and Codex, check how the combined allowance is counted before planning around it. If you manage tool budgets for a team, review plans and expected usage rather than assuming nothing changed. Test the Work features in Chat on a low-risk task before building them into a workflow. Sources https://www.bleepingcomputer.com/news/artificial-intelligence/openai-says-its-doubling-pro-usage-limits-and-bringing-work-features-to-chat/ https://x.com/BleepinComputer/status/2116891368458969535

  • DEV CommunityThe Giantsread at source

    Rotifer v0.9.4: Agents get a memory of their own (npm 0.33.0)

    Until now, a gene started every run from nothing. Whatever it learned about a user, a task or a recurring input was gone when the run ended. v0.9.4 gives every agent a memory. Its genes can read and write it between runs, through four calls, under rules the protocol defines: what kind of entry it is, who may read it, how much room there is, and how long it is kept. v0.9.4 is the protocol version (spec §38, Agent Memory). It shipped in @rotifer/playground 0.33.0 on 2026-11-01. Memory belongs to the agent, not to a gene An agent is a set of genes. Genes get replaced: a better formatter comes along, a gene gets a new version. If memory lived inside a gene, every swap would wipe what the agent had learned. So memory belongs to the agent. When you replace or update a gene, the agent's memory stays where it was, and the next gene can pick it up. Here is a formatter that remembers the indent width a user asked for last time: import type { GeneMemoryAccess } from " @rotifer/playground/memory " ; // reindent() is the gene's own formatting logic, not shown here. const KEY = " formatter/indent " ; export function express ( input : { code : string ; indent ?: number }, ctx : { memory : GeneMemoryAccess }, ): { formatted : string ; indent : number } { let indent = input . indent ; if ( indent === undefined ) { const saved = ctx . memory . readMemory ( KEY , " PREFERENCE " ); indent = saved ? Number ( new TextDecoder (). decode ( saved . value )) : 2 ; } else { ctx . memory . writeMemory ( KEY , new TextEncoder (). encode ( String ( indent )), " PREFERENCE " , ); } return { formatted : reindent ( input . code , indent ), indent }; } The entry gets the default access policy, so other formatting genes in the same domain can read it. Swap this gene for a better formatter in the same domain, and the new one finds the saved indent where the old one left it. Four kinds of entry, and what gets cleared first Every entry has one of four categories: Category What it holds Cleared when memory is full? PREFERENCE What the agent has learned about a user Never PATTERN Patterns noticed across repeated runs Yes, after CACHE CONTEXT Knowledge built up about a task or domain Yes, after PATTERN CACHE Results that can be computed again Yes, first Each agent has a quota, 10 MB by default. Set another one when you create the agent: rotifer agent create my-agent --genes my-gene --memory-quota = 50MB When a write would go over the quota, the agent makes room by removing the oldest CACHE entries, then PATTERN , then CONTEXT . PREFERENCE entries are never removed this way. If there is still not enough room, the write fails with MEMORY_QUOTA_EXCEEDED and nothing is written. Who can read what An entry says which genes may read it and which may change or delete it. The options are the gene that created it, genes in the creator's domain, or every gene in the agent. The default is the creator's domain ( SAME_DOMAIN ). The check runs before every read, write and delete. A gene that is not allowed gets MEMORY_ACCESS_DENIED , and the refusal is written to the agent's audit log. How long entries are kept An entry can carry maxRetentionDays . Once that many days have passed since it was last written, it is gone: reads return nothing, queries leave it out, and it no longer counts toward the quota. Each removal is logged. Seeing and clearing an agent's memory As the person who deployed the agent, you can look at its memory and clear it: rotifer agent memory list [ --category ] rotifer agent memory delete ( --key | --category ) list shows each entry's key, category, size, creating gene and last update. It never prints values. delete removes one key or a whole category, whatever the entries' access policies say, and each deletion is logged. It stays on your machine Memory is stored in your project's .rotifer/playground.db . Every change, and every refused access, adds a line to .rotifer/audit.jsonl . Both files stay on your machine; the CLI sends neither of them anywhere. Which genes get memory TypeScript genes that run on Node.js get the four calls as ctx.memory , as in the example above. Genes that bring their own WASM (Rust, AssemblyScript, WAT) call the rotifer.readMemory , writeMemory , queryMemory and deleteMemory host functions. TypeScript compiled to WASM cannot use memory yet. If a TypeScript gene needs memory, run it on Node.js. Memory only works inside an agent ( rotifer agent run ). To try a gene that uses it, run rotifer test : it gives the gene an empty memory of its own for the length of the test and then deletes it, so your agents' memory is not touched. The Memory API reference has the four calls, the error codes, the host-function interface and the size limits. The Cloud side: built and checked, not deployed The same memory model is implemented for Rotifer Cloud: a database schema and an agent-memory edge function, in the rotifer-playground repository. We ran the same set of operations through the CLI and through the Cloud implementation (against a local Supabase) and compared the results entry by entry: 39 of 39 matched in the main scenario and 32 of 32 in the expiry scenario. It is not deployed . Rotifer Cloud does not store agent memory today, and there is no command that moves an agent's memory to the cloud. It will be deployed when rotifer.ai's cloud agents connect to it. That is not part of this release, and it has no date yet. Also in this release rotifer run checks the schema. Input is checked against the gene's inputSchema before it runs, and output against outputSchema after. Input that does not match now exits 1; --no-validate turns both checks off. rotifer compile prints Gene ID (v2) , the id memory records as an entry's creator, and labels the content hash as not an identity. Fixes: wrapped genes compile again; a Par , Cond or Try agent that cannot run as written stops and says why instead of quietly running as Seq ; a gene stopped by its time limit is reported as a timeout; rotifer run works on Windows. τ is paused in the CLI too , and wasmtime is updated to 48.0.8 for the 2026-10-29 RustSec advisories. The full list is in the changelog . Where this sits The aim is agents that get better at their job the longer they run, while the genes inside them keep being replaced by better ones. That needs memory that outlives any single gene and rules about who can touch it. This release puts that in place on your machine. Not in this release: Cloud memory is not live. The Cloud implementation exists and matches the CLI, but it is not deployed. TypeScript genes compiled to WASM cannot use memory yet. autoDeleteOnTermination is stored but has no effect yet. No command moves an agent or its memory to another binding. Install / Upgrade npm install -g @rotifer/playground@0.33.0 This article was originally published on rotifer.dev . Follow the project on GitHub or install the CLI: npm i -g @rotifer/playground .

  • DEV CommunityThe Giantsread at source

    Google Expands UGC Spam Guidance for Sharing Platforms and Publishing Tools

    Google has expanded its guidance on preventing user-generated content abuse to explicitly include platforms, tools, and apps that enable people to publish shared pages, generated content, or web apps. The update matters beyond conventional forums and comment sections: it places more attention on the indexing and abuse controls used by third-party publishing and sharing services. The updated Google Search Central guidance on preventing abuse , last updated October 26, 2026, outlines steps platform owners can take to limit spam and monitor conditions that may lead to manual action. For businesses and agencies using external tools to publish content, the practical issue is whether those outputs are intended to be discoverable in Google Search and whether the platform has adequate safeguards. What Google changed in its UGC spam guidance Google's documentation now explicitly addresses hosting platforms and tools that let users create and publish content. This can include services that produce shareable pages, generated content, or web applications. The policy focus is not that every page created through such a tool is spam. Rather, Google identifies these environments as potentially vulnerable to abuse when users can publish large volumes of low-quality or manipulative pages. A platform may therefore need to manage both the content people create and which content it allows search engines to index. This broadens the operational meaning of UGC spam. Historically, many site owners associated UGC controls with blog comments, discussion boards, reviews, and profile pages. Google's updated language brings publishing infrastructure itself into clearer view, particularly where a service can make user-created outputs publicly accessible at scale. Only index content intended for Search A central addition to the guidance is Google's recommendation to only index content meant for Search . In practice, that means platform owners should establish a deliberate policy for pages that are created to be shared privately, used temporarily, or otherwise not intended for broad search discovery. Google lists several ways to limit indexing of such pages: Applying a noindex directive through a meta robots tag. Sending a noindex directive through an X-Robots-Tag HTTP header. Blocking crawling in robots.txt . The important strategic point is intentionality. A URL being public or technically accessible does not necessarily mean it should become a searchable landing page. Share links, generated previews, utility pages, and user-created outputs can all increase a platform's indexable footprint. If those pages do not provide a useful search result, allowing them to proliferate can create avoidable quality and spam-management risk. For organizations that publish through third-party tools, this is also a vendor-governance question. Teams should understand whether a platform creates crawlable URLs by default, whether indexing settings are available, and whether those controls can be applied consistently across users and templates. Google emphasizes preparation and monitoring The revised guidance also advises platform owners to prepare for abuse signals rather than waiting for an enforcement event. Google recommends verifying a site in Search Console so eligible site owners can receive alerts and regularly reviewing indexing and performance reports for unusual changes. It also points to platform-level operational metrics. Monitoring the rate of content creation and indexing can help identify abrupt shifts, such as a surge of new URLs or indexed pages that does not align with normal publishing activity. Those anomalies may warrant an investigation into automated publishing, compromised accounts, low-quality submissions, or other abuse patterns. This is not a published enforcement schedule or a declaration that a new manual-action program has begun. Google's guidance describes prevention and potential enforcement pathways, while the specific classification of individual platforms, regional timing, and measurable effect on indexing remain unclear. Still, the documentation gives platform operators a more explicit framework for reducing UGC-related risk. What site owners and agencies should audit The update is most directly aimed at platform owners, but businesses that rely on external publishing services have a reason to review their exposure. A brand can create content on a third-party system without controlling all of the technical decisions that determine whether pages are indexed or how abuse is handled. Start by mapping the services that create public or shareable URLs under your domain or a provider's domain. This may include collaboration tools, customer portals, marketplace listings, templated microsites, form-generated pages, community features, and app builders. Then distinguish between content that is genuinely designed to earn search traffic and content that exists only for a user workflow. A practical review should cover: Which user-created or generated page types can be crawled and indexed. Whether pages not intended for organic discovery have an explicit indexing policy. Whether publishing permissions, moderation, and abuse reporting are appropriate for the platform's scale. Whether Search Console access and alerts are configured for owned domains. Whether teams review indexing and performance changes alongside content-creation volume. Agencies should include these checks when evaluating client sites that use subdomains, hosted communities, or embedded publishing products. An unexpected rise in indexed URLs is not proof of a policy violation, but it is a useful prompt to investigate the source and quality of newly discoverable pages. Why this affects organic visibility Indexing controls are not simply a technical housekeeping task. They influence the set of pages Google can evaluate as part of a site or platform. If a system permits large numbers of thin, duplicate, automatically generated, or spam-oriented pages to enter the index, the issue can affect more than those individual URLs. Google's revised guidance makes clear that UGC spam prevention is a platform responsibility as well as a content-moderation responsibility. The strongest response is not indiscriminate blocking. It is a documented approach that permits valuable public content to be found while restricting pages that serve no search purpose. For SEO teams, that requires closer coordination with product, engineering, and vendor-management teams. Decisions about share URLs and default publication settings can have search consequences long before a content team notices a problem in reporting. If your site relies on user-created, generated, or shareable pages, create a GEO Search Leads account to begin assessing your website's GEO readiness and identify optimization opportunities around discoverability, content accessibility, and indexable page quality. It can help establish a clearer baseline for the pages you want search systems and AI-powered discovery experiences to understand, while supporting more informed technical and content reviews. Frequently Asked Questions Does Google's updated guidance mean all user-generated content is spam? No. Google's guidance addresses the risk of abuse in environments where users can publish content. It does not state that all user-generated content or all sharing platforms are spam. Which pages should be noindexed under the new guidance? Google recommends limiting indexing to content intended for Search. Pages created for private sharing, temporary workflows, or other non-search purposes may need an indexing control, depending on how the platform is designed and used. Can businesses using third-party publishing tools be affected? They may need to assess the search implications of those tools, especially when they create public URLs or pages under the business's domain. The update places particular emphasis on platform-level controls and monitoring. What should teams monitor in Search Console? Google recommends verifying the site to receive alerts and checking indexing and performance reports for anomalies. Platform owners should also track content-creation and indexing metrics for unexpected spikes. Conclusion Google's revised UGC spam guidance extends the conversation from moderating individual submissions to governing publishing systems and their indexable outputs. Platforms and the businesses using them should make deliberate decisions about what belongs in search, apply suitable controls to pages that do not, and investigate unusual indexing patterns before they become larger visibility or compliance issues.

  • DEV CommunityThe Giantsread at source

    Gibbon discovery should separate school data from the login page

    Gibbon discovery should separate school data from the login page Gibbon is school management software that brings student profiles, attendance, assessment, enrolment, and communication into one web application. The visible landing page may be a login screen or a public admissions form. The security question begins with the permissions attached to each role and the records those roles can reach. A count-only ZoomEye query for app="Gibbon" returned 872 matches. The title="Gibbon" query returned 632. Both used sub_type=all , page 1, and pagesize 1. The near overlap is a useful deployment signal, but a matching product name does not establish that a school's records are exposed. It identifies candidate hosts for ownership and authorization review. Review roles and public settings Gibbon documentation describes student profiles as a central component that administrators and teachers use to access information, with visibility depending on Manage Permissions. It also distinguishes public and authenticated admission forms. Those settings are examples of why a site can be intentionally reachable while still carrying different data for different identities. Inventory the administrator, teacher, parent, student, and support roles. Ask which modules each role can open and which records it can change. Pay particular attention to impersonation, messaging, individual education plans, medical or safeguarding fields, and access to student contact details. Gibbon has added OAuth2 login handling and changed authentication-related areas in recent releases. The exact version and provider configuration matter. Verify the effective redirect, account-matching rule, and default role for an external identity. A directory account that is valid for a school's email domain should not automatically receive an administrator role. Test public forms and private portals Use an unauthenticated session, a parent account, a teacher account, a school administrator, and a support account with limited permissions. Confirm which pages and API calls each can reach. Test the public admissions form separately from the staff portal, because one may intentionally accept anonymous submissions while the other must reject them. File uploads, messages, and profile photos may have different access checks from the record pages that link to them. Request a known file through a valid and invalid session. Do not collect or publish student data while testing. Use synthetic records in a controlled environment where possible. Check session lifetime, password reset, and account deactivation. A parent who leaves the school or a staff member who changes roles should lose the corresponding access. External identity group changes need a measurable effect in Gibbon as well as in the identity provider. Treat count differences as a coverage note The 872 app matches and 632 title matches are close enough to suggest some fingerprint consistency, but the difference still matters. A school can customize the title, run a portal under another name, or expose an application endpoint without the visible label. An owner should resolve the host before applying a version-based conclusion. Monitor authentication failures, role changes, permission changes, impersonation events, and access to sensitive student records. Correlate the application event with the identity provider and the responsible administrator. Keep the audit record free of unnecessary student details. The useful outcome of a Gibbon inventory is not a list of 872 supposedly vulnerable schools. It is a reviewed set of hosts with an organization owner, a confirmed login policy, a role map, and evidence that sensitive records and public forms are separated. That evidence takes the count from an index result to a defensible security decision. References Gibbon: Student Profile Gibbon: Student Enrolment Gibbon: Versions

  • DEV CommunityThe Giantsread at source

    I Wanted a Workout Tracker That Respected My Data, So I Built KOVA

    Building an offline-first fitness application focused on privacy, personal training history, and putting users in control of their own data. Fitness applications have an interesting business model. You track your workouts, record your progress, build routines, and gradually accumulate months or even years of personal training data. But where does all that information actually live? For many applications, your training history depends on an account, a cloud service, or a subscription. I started thinking about a different approach. What if a workout tracker could be genuinely useful without requiring users to depend on a remote service? That idea became KOVA . Explore KOVA Your training history should belong to you A workout tracker should be relatively simple in principle. You perform an exercise, record your sets and repetitions, track your progress, and use that information to make better training decisions. Yet, over time, these records become something more valuable than individual workout entries. They become your training history. Your personal records, routines, measurements, exercise preferences, and progress represent actual effort accumulated over months or years. I believe that information should remain under the user's control. That's the philosophy behind KOVA. More than recording sets and repetitions KOVA is designed as a broader training companion rather than a basic exercise logging application. Here are some of the areas it brings together. 1. Workout tracking Record exercises, sets, repetitions, and training sessions. The objective is to make logging straightforward enough that tracking doesn't become more annoying than the workout itself. 2. Workout planning and routines Organize training sessions and create routines around your training preferences. Having a structured plan makes it easier to stay consistent and understand what you're working toward. 3. Exercise library Browse exercises and use an organized exercise library when planning workouts. A good exercise library is more than a list of names. It helps make workout planning and tracking easier to navigate. 4. Progress tracking Track your training history, personal records, measurements, and progress over time. Instead of relying entirely on memory, you have a record of what you've actually accomplished. 5. Training journal Keep notes and additional context around your training. Numbers tell part of the story. Sometimes you also want to remember how a session felt or what you changed. Offline-first is a design decision One of the central ideas behind KOVA is that a workout tracker shouldn't need a permanent internet connection to remain useful. An offline-first approach changes how an application is designed. Instead of treating a remote server as the only source of truth, the application prioritizes local data availability. This has practical advantages: Your workouts remain accessible without an internet connection. Logging doesn't need to depend on network availability. Your training experience isn't built around a cloud service being online. Your personal records remain part of your own application experience. Offline-first doesn't automatically guarantee perfect privacy or data security. Those still require deliberate engineering decisions. But it creates a foundation where the user doesn't have to depend on a remote service for every interaction. Designing around the actual workout experience A fitness application has a different usability problem from most productivity applications. People don't necessarily want to spend several minutes navigating menus between sets. The interface needs to make common actions easy to reach. That's why KOVA brings together workout sessions, routines, exercise browsing, progress, notes, and personal training information into one application. The design direction is intentionally restrained, with a dark, minimal visual language rather than overwhelming dashboards and unnecessary decoration. The application should support the training experience, not compete with it. Building KOVA KOVA has also been an interesting software engineering project because of the number of interconnected features involved. Workout tracking, exercise libraries, routines, measurements, and progress statistics all depend on consistent underlying data. Changing one part of the application shouldn't accidentally break another. This makes architecture and data integrity particularly important. The project has involved working through challenges around: Managing structured exercise and workout data. Keeping training records consistent. Designing reusable exercise and workout experiences. Supporting offline-first workflows. Making progress information understandable. Maintaining a cohesive mobile experience. I wanted to approach it as a proper training platform rather than a collection of disconnected screens. The bigger idea: your training, your data Technology should make personal progress easier to understand, not create unnecessary dependencies. A workout tracker shouldn't make you feel like you're borrowing your own training history. KOVA is built around a simple principle: Your training. Your data. Yours. It's an ongoing project, and there's still room to improve the experience, expand its capabilities, and refine how people interact with their training history. Try KOVA If you're looking for a more private, offline-first approach to workout tracking, explore KOVA: Visit KOVA I'm interested in hearing from people who care about fitness tracking, offline-first applications, privacy-focused software, and building products that give users more control over their data. Because at the end of the day, your progress should belong to you.

  • Hacker News Front PageThe Giantsread at source

    Proving and Improving the Platonic Representation Hypothesis with JEPAs

  • Hacker News Front PageThe Giantsread at source

    The "Moon Trees"

  • Hacker News Front PageThe Giantsread at source

    Everyone Has Email. Nobody Uses It Right

  • Hacker News Front PageThe Giantsread at source

    noyb win: French electronics retailer Fnac Darty fined €7M

  • Hacker News Front PageThe Giantsread at source

    Norway makes shithouses great again

  • CSS-TricksThe Giantsread at source

    CSS-Tricks has a new owner!

    Yes, I've got the keys to the castle, so to speak. And, even after 12 years of working on the site, I'll admit I'm a little overwhelmed and nervous about that. CSS-Tricks has a new owner! originally handwritten and published with love on CSS-Tricks . You should really get the newsletter as well.

  • Smashing MagazineThe Giants3 min read

    Accordion Icons: Which Work Best?

    A closer look at accordion icons, why split menus are harmful, and why it’s better not to have icons and text labels link to different actions. Plus, why the caret is the safest icon choice. You’ll find more [useful guides](https://www.smashingmagazine.com/category/guides/) and [online workshops](https://smashingconf.com/online-workshops) here on Smashing Magazine, so make sure to browse and explore.

  • Smashing MagazineThe Giants15 min read

    Embracing Playful Imperfection With The CSS `random()` Function

    Design systems thrive on consistency, so where does randomness fit in? Through playful demos of organic typography, bouncing letters, and splayed cards, Brecht De Ruyte shows how the new CSS `random()` function brings a little imperfection to the web without JavaScript libraries or preprocessor loops that generate hundreds of lines of static CSS.

  • Smashing MagazineThe Giants10 min read

    Is Your Organization Messing Up AI Adoption?

    What can digital transformation teach us about AI adoption? Paul Boag revisits his book Digital Adaptation to show how lessons from the past can help organizations navigate the challenges of AI today.

  • Smashing MagazineThe Giants6 min read

    A Practical Guide To Naming Things

    A practical guide to naming UI components, with useful resources, naming conventions, and structures. You’ll find more [useful guides](https://www.smashingmagazine.com/category/guides/) and [online workshops](https://smashingconf.com/online-workshops) here on Smashing Magazine, so make sure to browse and explore.