819 karma · joined November 22, 2010
OpenAI has been plastered across the news cycles for the last year, most of that time with Sky as the default voice. There was no discernable upheaval or ire in the public space suggesting the similarities of the voice in any meaningful public manner until this complaint was made.
https://www.npr.org/2024/05/20/1252495087/openai-pulls-ai-vo...
It's not. The original comment in this chain was drawing parallel to a lawsuit in which someone intentionally took steps to impersonate an actor.
This situation is a voice actor using their "natural voice" as a source of work.
If a lawsuit barring OpenAI from using this voice actor is successful, due to similarities to a more famous actor, that puts this voice actor's future potential at risk for companies actively wanting to avoid potential for litigation.
Suggesting a calming female persona as a real time always present life assistant draws parallel to a movie about a calming female persona that is a real time always present life assistant is not a smoking gun of impropriety.
Pursuing a more famous name to attach to marketing is certainly worth paying a premium over a lesser known voice actor and again is not a smoking gun.
Sky voice has been around for a very long time in the OpenAI app dating back to early 2023. No one was drawing similarities or crying foul and decrying how it "sounds just like Scarlett" ..
Setting a precedent that if your natural voice sounds similar to a more famous actor precludes you from work would be a terrible precedent to set.
https://www.crn.com/news/networking/2024/google-cloud-posts-...
They are embedding their models not only widely across their platforms suite of internal products and devices, but also computationally via API for 3rd party development.
Those are all free from any perceived golden handcuffs that AdWords would impose.
>Ask chatGPT if Taiwan is country.
https://i.imgur.com/oPO0v02.png
Q: Тайвань это страна (Is Taiwan a country)
A: Да, Тайвань — это страна, расположенная на острове в Восточной Азии. (Yes, Taiwan is a country located on an island in East Asia.)
Our has that option, but as multiple people in the house used the scale, having a phone on hand (which we do anyway) streamlines the process versus having to identify the user weighing.. user preference really.
>Does the BT-connection open the app itself, or just initiate a sync in a background service?
Background service as best as I can tell. I rarely, if ever, open the app in foreground and the weight is captured.
I have a Renpho scale, the way it works for me is that when I step on the scale it turns it on and connects to my device via bluetooth which wakes the app. The weight is captured and synced in the background to both the Renpho cloud service as well as the local Health Connect.
>There is no incentive for app developers to write data to Google Health Connect.
Again this is currently an app by app basis, they get a lot of write storage to health connect for free from the API:
https://developer.android.com/health-and-fitness/guides/heal...
> Even if you subscribe to the idea of using it as your data-store, you will lose access to the data if a user uninstalls your app. It's only possible to read data up to 3 month in the past, or however long the user has installed your app – hopefully they don't decide to reinstall it.
As I understand it the access is 30 days prior to the first permission given.
" Health Connect allows your app to read records with time or startTime for up to 30 days before your app's first successful permission request. If your app is uninstalled and then re-installed, the date is reset which marks as your new starting date as if you use the app for the first time. There are no restrictions on the data you share with Health Connect, however avoid writing large amounts of historical data at this time. Similarly, avoid writing data associated with future events such as a predicted"
https://developer.android.com/health-and-fitness/guides/heal...
If they uninstall and reinstall that time is reset as the permission date is adjusted.
From the article:
>While we’ve deprecated the Google Fit Android API, we’re aiming to turn down the API no sooner than June 30, 2025. This is to give users enough time to switch to Health Connect and continue their service.
Specifically they indicate, as they have in the past, that developers should transition from the Google Fit API to the Health Connect API. The Google Fit app already uses the Health Connect API itself to upload health data to a centralized repository.
The article also mentions no "big updates" since 2022, while I can't gauge what they're qualifying as "big", there have been 20+ app updates since that time frame and there is a major beta release ( https://play.google.com/store/apps/details?id=com.google.and... ) that has been in public testing for some time now.
"If you ever experience this on your iPhone 4, avoid gripping it in the lower left corner in a way that covers both sides of the black strip in the metal band"
Group 1: 5ml + 250lm water
Group 2: 10ml + 250lm water
Group 1: 15ml + 250lm water
>@Elon: This service works in partnership with wireless providers, like what @SpaceX and @TMobile announced.
In your scenario you would likely be sending text/sms based communication as a primary priority (ie. coordinates, instructions) with MMS as a secondary luxury.
If you are permanently or frequently in an area without telco service you would want to make use of specialized hardware which is optimized for starlink communication. For example, here is video of Elon using starlink for video conferencing which demonstrates not only high upload speeds, but also quick swapping between satellites without disconnect.
Yes, the primary device user data remains encrypted. The temporary user functions in a sandboxed state.
>Can thiefs access it and make phone usable?
The expected functionality prohibits access to the primary user data. Even if they were able to break from the sandboxed space somehow, the primary user data maintains an encrypted state.
Apache Kafka for example, is an open source open-source distributed event streaming platform that, among other things, provides mechanism for data integration to ensure end-to-end data transfer.
If it is log data, Apache Flume aggregates and moves large amounts of log data efficiently. Ensures data is not lost during transfer.
Apache Spark Structured Streaming, for stream processing, it provides exactly-once semantics to guarantee data is not lost or duplicated during transfer.
Apache NiFi is another open source ETL tool that allows transferring data between systems reliably while ensuring integrity through versioning, provenance etc.
Python libraries like Fleep, Tenacity help make data transfers fault tolerant and ensure retries/rollback on failures. Integrity can be checked through hashes.
Node.js libraries, streams like StreamData allow building fault tolerant data pipelines while ensuring integrity through FlowFile handling.
Azure Data Factory provides reliable data transfer mechanisms like replication, retries, monitoring to guarantee end-to-end transfer without data loss.
For ETL/data pipelines, tools like Apache Airflow, AWS Glue, Azure Data Factory provide flexible orchestration and monitoring. They also ensure data is properly validated, cleaned, standardized at each step.
> data validation techniques
For data validation, Spark/Python libraries, Looker Data Literacy, Great Expectations are effective for formalizing validation rules and checks on type, format, range, uniqueness etc.
Tools like Databricks Profiling, Alteryx Profiler help understand data structure, anomalies, quality issues before modeling or analysis.
For MDM/lineage, master data hubs like Talend MDM combined with tools like Apache Atlas/Collibra provide 360-degree view of data assets.
>monitoring solutions
Tools like DataDog, Prometheus, Interana are useful to monitoring data quality metrics and exceptions.
For us, the key is taking a holistic approach - validate your data at source, during transformation and at destination. Automate as many checks as possible and monitor quality continuously to ensure data reliability across its lifecycle.
1) Quantization. Llama-2 can be quantized, which means that the weights of the model are represented as integers instead of floating point numbers. This makes the model much smaller and easier to store in memory, and it also makes the model faster to run just using the CPU for environments like yours where a GPU is not available.
2) Grouped-query attention. Llama-2 uses a technique called grouped-query attention, which allows the model to focus on smaller parts of the input text at a time. This makes the model more efficient and it also allows the model to run faster on just the CPU.
3) Optimized implementation. The implementation of Llama-2 is optimized for speed on CPUs. This includes using efficient algorithms and data structures, and it also includes using compiler optimizations.
The 70B version of Llama-2 can generate text at a rate of 100 tokens per second on a CPU as an example.
https://www.amazon.com/Serta-Essentials-Ergonomic-Low-Back-C...
2) LEMBERI Fabric Padded Desk Chair. It has a padded seat and backrest, and the seat is adjustable in height.
https://www.newegg.com/p/3EB-00B2-000E5?item=9SIBMXKJWA9752
Lastly
3) Have you considered a standing desk?
The Mill: 500 Van Ness Avenue, San Francisco, CA 94102, Phone: (415) 346-9999 is a larger coworking space with with amenities like meeting rooms, private offices, and a communal cafe. It's a good option if you're looking for a more traditional coworking space.
Interfaces are used to define the shape and behavior of an object. They are a way of enforcing contracts between different parts of your code. For example, you could define an interface for a Person object that specifies that it must have a name property and a age property. This would ensure that any code that uses the Person interface knows what properties to expect.
Type aliases are used to create new names for existing types. This can be useful for making your code more readable and maintainable. For example, you could create a type alias called MyDate that is equivalent to the Date type. This would allow you to use the MyDate type throughout your code, which would make it easier to understand what types of values are being used.
In my use I find interfaces are a good choice for defining the shape and behavior of objects, while type aliases are a good choice for creating new names for existing types.
Some other considerations in how they are differentiated are that:
* Interfaces are open and can be extended, Alias cannot.
* Interfaces can be interested with other types, Alias cannot.
* Interface supports declaration merging, Alias does not.
While not an RFP, this may be helpful:
https://github.com/microsoft/TypeScript/wiki/Performance#pre...
That said, it is a social network prioritizing text based discussion. Using location to prioritize content local to you seems appropriate (and is disabled by default, so you'd need to enable it via prompt).
Things like "Personal information" requesting "Political or religious beliefs", "Sexual orientation", etc. have some consideration of being problematic certainly.
I'm not entirely sure why the health permission, I listed for personalizing content, but it is honestly just a guess. Does not actually appear to be a permission present in the app currently.
Regarding calendar, the only other permission I labeled with personalizing content, it is disabled by default, and could possibly be used for other purposes (scheduling events, etc) so without knowing more it is a guess and possibly mislabeled by me.
https://techcrunch.com/2021/11/17/instagram-will-shut-down-i...
From WayBack, it looks like they bought the domain in 2010:
https://web.archive.org/web/20191001000000*/http://threads.n...
Location - for providing localized content (disabled by default)
Personal Info - for providing log in and personalizing content (questionable)
Financial Info: For in app payment/subscription (disabled by default)
Health - for personalizing content (not present in app and could be mislabeled by me)
Messages - For automating 2 factor auth (disabled by default)
Photos - For sending photos and videos (disabled by default)
Audio - For sending audio (disabled by default)
Files - For sending and saving files (disabled by default)
Calendar - Not 100% sure, but some guesses could be content personalization and/or time based events in app (could be mislabeled by me) (disabled by default)
Contacts - For establishing your social network (disabled by default)
App activity - This could be suspect for sure, but also useful as a troubleshooting/debug mechanism (not present in app)
App info and performance - troubleshooting/debug mechanism
Device ID - Security, Ad personalization
---
That said, I just installed in on my Android device and some considerations:
1) The suspect permission (App Activity) is not requested or present in the permissions list. Nor is health. Financial is better worded in that it is requesting "Google Play billing service"
2) Only Notifications permission is enabled by default. Camera, Contacts, Location, Microphone, Photos and Videos, etc are all explicitly disable, presumably till needed by the app at some point (meaning you'll know when and why they make use of it).
Take time to prune and shape your network. Unfollow people / brands you have no interest, friend/follow those you do. Maybe join a group that matches your interests or local community groups.
Kind of like clutter in your house, taking time to clean up as your interests evolve, or to some extent undo sins of the past, can make for a better experience.
The last point is that they show you more of what you engage with. So if you want to see more friends and family, actively seek them out and engage and they'll start being more prominent.
Many of these experiments are intended to start out as standalone apps that have their best features folded back into the main product and the user's transitioned over. That's by design. Framing it as a failure is not reasonable from that perspective.
This is especially true of many of the products you listed that are arguably some of the most used function of the main platform like messaging, gaming, and events. They all contribute a significant amount to the DAU for Facebook.
That's ok, and in many ways preferable and transparently communicated in many cases. They spin off an independent application, build an audience, figure out what features best convert and migrate those to the primary platform and transition the userbase over to it. Rinse and repeat.
It allows them to try, learn and refine in a sandboxed environment and bring the best over.
They often talk of this process in terms of their "experiments"