For the best experience on desktop, install the Chrome extension to track your reading on news.ycombinator.com
Hacker Newsnew | past | comments | ask | show | jobs | submit | history | samsk's commentsregister

Earlier attempts were mostly about money and ideology. Now its a question of security, thanks to one 'clever' 'businessman'. So thanks to his _great_ efforts, it might actually work out this time.

Interesting tool, will definitely try - just curious, is there a tool (hexora checker) that ensures that hexora itself and its dependencies are not compromised ? And of course if there is one, I'll need another one for the hexora checker....


There is no such tool, but you can use other static analyzers. Datadog also has one, but it's not AST-based.



We work with MLS provider(s) that requires us to keep plaintext password for our users and provide it on request in case of `breach in the security of MLS Listing Information or a violation of MLS Rules`.

The user is accessing only copy of their data in _our_ systems, the user has no contact with MLS itself directly or indirectly.


...and costs pennies compared to putting anything up there, so it can even enjoy those cosmic goodies.


No grep ? We are lost !


Who would tell. Economy runs on 'trust' - not on 'by tomorrow we apply this random tax rate to this pinguin island and everone else'.


Trend has been negative since 1999 so as much as I like to poke the tango doll, this can not be the reason or only reason.


I’m still working on MLSync.io, an ETL platform designed to remove the technical friction of synchronizing MLS data using RESO protocol and provide simple access to the MLS data via SQL and REST API.

And as everyone now, I'm experimenting with LLMs to bring some new AI-related features to the service.

On another project, we've now beta testing (in ordination) Asus GX10 processing power running on-device LLMs for _local_ processing of patient medical data for 'differential diagnoses, implant plans and risk profiles in real time while the patient is in still in the chair'.

[1] https://MLSync.io


My tl;dr is: Don't do huge updates using WHERE on fields _not_ in index, otherwise it will take days to finish and you get meaningless numbers in benchmarks...


I learned that in a hard way. It was midnight, I had to make some urgent changes to the user table in the production database. We had about 4 million users and needed to make changes to 70k users (due a change in 3rd party).

I figured out after 40 minutes that we are not making any progress. For each user we are probably searching 4 million users. After I added the index to a specific field, it was done quickly.


Oddly enough, for a big enough update, postgres sometimes will do the math and decide that scanning the whole table is faster than scanning the index and then scanning a certain fraction of the table (considering also that it has to rewrite the entire page if any row in the page is updated)


Can happen, but on the BAD website will the password manager not offer saved password, so user has higher chance of noticing smth. is wrong. Of course if he uses pass manager with complex passwords...


SEEKING WORK | Remote | Worldwide (EU-based, GMT+1) | Part-Time

PERL Expert | DevOps Engineer | SQL/SOLR Specialist

Language: English, German

Areas of expertise:

    • Legacy PERL Code Maintenance
    • PERL Performance Optimization
    • PERL Security & Compliance
    • Migration Services
        → PERL to Python Migration
        → Database Version Upgrades
        → Legacy System Modernization
Other notables experiences:

    • Prometheus based monitoring systems
    • Cloud / On-premise inventory systems and synchronization to CMDB/ITSM
    • MLS data synchronization via RESO/RETS - https://mlsync.io
WEB: https://perlexpert.de/en/

Email: ja.hn4[at]mailgw.com


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search:

HN For You